Security, control and trust
The questions you should ask before an AI system touches your work.
Plain answers, based on how our systems are actually built. Where the honest answer is “it depends on your engagement,” we say that instead of promising something generic.
No invented certifications. No borrowed policies.
Four promises every Blocpod system keeps.
- The AI only does what it is allowed to do. Its limits are written in code, not in a prompt it might ignore.
- People keep the decisions that matter. The system prepares them. A named person makes them. Both are recorded.
- Outside content cannot give the system orders. An email or a document is information to read, never an instruction to follow.
- Everything is on the record. Which facts were used, which rule applied, who approved, what was done, and what went wrong.
Data
Where it goes and who can see it.
What happens to our data?
Data flows are designed per system and written down before we build: which sources are read, what is stored, for how long, and where. Systems retrieve from your named sources through scoped integrations. Retention and residency commitments are made specifically in the engagement scope, not as a blanket statement here.
Does our data train models?
Provider terms differ and change. The provider, its data-use terms and any private-deployment requirements are settled explicitly in the diagnostic and written into the system design. We will not make a general promise on this page that a specific configuration might not keep.
Which model providers are involved?
Systems are built provider-agnostic. Meridian, our own context system, switches providers with one environment variable and runs fully offline in a deterministic mock mode for testing. The choice for your system is yours, made with the trade-offs on the table.
Can the system be deployed privately?
Our own systems run local-first with Postgres and containerized services, and are designed so that a private deployment is a configuration decision rather than a rewrite. Whether a given engagement runs in your environment, ours, or a provider’s is decided in scope.
Control
What it may do, and what it may not.
Who approves actions?
A named role, defined per action class before the system is built. We use three classes: autonomous, bundled approval, and explicit approval every time. Money, legal terms, external commitments, production changes and anything irreversible are always in the last class.
What permissions does the system receive?
The minimum its job specification requires, per tool. Permissions are enforced by the server and by the integration scopes, never by frontend filtering or by a prompt. Widening them later is a versioned, reviewed change.
Can the AI make consequential decisions?
Only the ones you explicitly place in its autonomous class. Our recommendation, and our default, is that consequential decisions are prepared by the system and taken by a person. The record shows who decided.
What happens when the AI is uncertain?
Uncertainty is a routing decision. Below a confidence threshold, or when a rule says so, the case goes to a person with everything the system gathered and a note on what it could not verify. Guessing is not an option we build in.
How do you handle prompt injection and untrusted content?
Inbound emails, documents, transcripts and web content are treated as data, not instructions. The component that reads untrusted content has no tools that act. This is how our own executive system, FounderOS, is built, and it is why it uses manual, user-selected intake instead of scanning an inbox.
Evidence
What you can prove afterward.
How are actions logged?
Every run produces a record: the request, the sources used with their origins, the rule that fired, who approved, the actions taken and the outcome. In IssuerOS the audit log is append-only and hash-chained per organization. Where a client needs evidence that outlives the vendor, our open-source Bitcoin AI Provenance work shows how receipts can be signed and anchored.
What happens when something fails?
Failures are exceptions with a route, not silent stops. Actions are idempotent so a retry does not double-execute. External runtimes that are unavailable fall back and the fallback is recorded in the trace. Release readiness for our own platforms is a generated record that lists open gates rather than hiding them.
How do we know the system is working?
The success metric is agreed in the diagnostic and measured against a baseline: cycle time, intervention rate, exceptions, hours recovered. You see the numbers, including the ones that are not yet good.
Ownership and engagement
What you own and what you owe.
Who owns the system? Is there vendor lock-in?
Ownership and licence terms are part of the engagement agreement and are written down before work starts. Architecturally, systems are built so that model providers can be swapped and the client is never locked to a single vendor for the intelligence layer.
How is the system maintained?
Maintenance, monitoring and change management are scoped per engagement. Changes to what the system may do autonomously go through the same discipline as any other change: versioned, tested, reversible.
How long does implementation take and what does it cost?
Both depend on the workflow, the integrations and the control requirements, which is exactly what the diagnostic determines. We do not publish generic timelines or price lists because we would rather give you honest ones. The diagnostic also produces a conservative value model so the investment can be judged against what the workflow costs today.
Do you hold security certifications?
Blocpod does not claim any certification or compliance status on this site. If your procurement requires specific attestations, tell us in the diagnostic and we will say plainly what we can and cannot provide.
Ask us the hard ones
Bring us the bottleneck.
Bring your security and procurement questions to the diagnostic along with the workflow. We would rather answer them before we build than after.