Architecture
One control plane. Three planes of work.
The control plane holds identities, the agent graph and policies. The runtime plane authenticates, authorizes and enforces on every governed call. The evidence plane records the decisions Praesidia makes in a hash-chained trail, signed under the default configuration, that you can verify offline.
The system
Three planes, one path through them
Control plane
What you configure, once.
- Identity
- AI System Graph
- Policies
- Configuration
Runtime plane
What happens on every governed call.
- Authentication
- Authorization
- Policy Evaluation
- Approval
- Enforcement
Evidence plane
What you hand to an auditor.
- Events
- Decisions
- Hash Chain
- Signatures
- Export
Praesidia sits on the connection between your agents and everything they reach, so nothing has to be rewritten to be governed.
The enforcement path
One governed call, end to end
What happens between an agent and the thing it is trying to reach, and what is left behind afterwards.
Agent / App
Makes the call.
- AI agents
- Applications
- MCP clients
Praesidia enforcement
Decides before the call leaves.
- Which agent is asking
- Is this tool allowed here
- Allow, deny or hold for a person
Tool / MCP / API
Reached only after the decision.
- MCP servers and their tools
- Model providers
- APIs
Evidence written
Decisions — allowed, denied or held — are recorded in the append-only audit trail, signed and hash-chained under the default configuration.
Boundaries
Where the lines are drawn
- Tenant boundary
- Every request is scoped to the calling organization. The evidence trail, the agent graph and the policies are held per organization, and one organization can never read another's.
- Evidence boundary
- The trail covers what passes through Praesidia: governed calls, the decisions on them, and changes to configuration. Traffic that bypasses the platform is not in it. An exported bundle can be checked offline by your team or your auditor, without calling our servers — see what the check proves and what it does not.
- Region
- Praesidia's production app, API, MCP server and model gateway run on Amazon Web Services in the eu-central-1 region (Frankfurt, Germany), and the data those services store is held in that region. The website and the app are delivered through Amazon CloudFront, which terminates TLS at edge locations in North America, Europe and Israel before requests reach Frankfurt, so we do not describe the data path as EU-only end to end; API, MCP and gateway connections terminate TLS in Frankfurt. Cloudflare provides DNS only and does not carry requests. Each provider and the region it runs in are listed in the service provider inventory; more on the Trust Center.
- Deployment
- Every Praesidia organization today uses the same shared SaaS service — the only deployment mode currently in production. Every request is scoped to the calling organization.
- Dedicated instance
- Dedicated is a single-tenant instance of the same platform, provisioned for one organization. It is scoped and provisioned per signed engagement, not a self-serve purchase, and no dedicated instance is in production today — talk to us to discuss whether it fits your requirements. See deployment options.
For security review
How it answers the questions reviewers ask
- Where data flows
- Agent traffic routed through Praesidia reaches the runtime plane first: which agent is asking, whether the tool is permitted on that connection, and what the arguments actually say. Traffic that bypasses the platform is neither inspected nor recorded.
- What gets stored
- Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. Praesidia also stores the agent graph, the connections and the policies you configure. A signed record shows it was not changed afterwards. It does not show that every action was captured.
- Credentials
- Each agent authenticates with its own attributable, individually revocable credential, and gets short-lived capability credentials for work it performs. Provider keys and agent credentials are vaulted — shown once, never exposed in logs or read back in plaintext.
- Tenant isolation
- Each organization's data is isolated from other organizations'.
- High availability
- We do not claim automatic failover for today's production deployment, and no live failover drill has been run. Availability commitments, response times, and support severities are set contractually, not published as a general number here — talk to us. What happens when a dependency fails is in the table below; what we measure and drill is on the Trust Center.
- Failure behaviour
-
By default, if the enforcement point cannot reach the control plane, governed calls are refused rather than let through unchecked.
A revoked key can keep working at the enforcement point for a short window — minutes, not hours.
- Latency
- If the control plane is slow to answer, a governed call is not left hanging: by default it is refused within seconds. Measured proxy overhead is p50 0.332 ms · p90 0.927 ms · p99 3.39 ms, from our own release measurement under the conditions it states — see the measurement and its caveats.
- Retention
- No retention period is published here; it is available on request during security review — ask security@praesidia.ai via the Trust Center.
- Encryption
- Encryption in transit and at rest. Audit records are signed and hash-chained under the default configuration, which an operator can turn off; regulated deployments hold their own signing key (BYOK), and external anchoring to the public Sigstore Rekor transparency log is opt-in.
Then: runtime enforcement · the agent graph · verify the evidence yourself.
Tested, not assumed
What happens when a dependency fails
Each row below is exercised by our own fault-injection test suite, not a design intention — a failure mode we have not tested is left off this table rather than assumed to be handled.
| What fails | What the platform does | What you see |
|---|---|---|
| The gateway cannot reach the control plane at startup | It refuses to start rather than come online without policy enforcement in place | No requests are served in a degraded, unenforced state — the service does not come up until the control plane is reachable |
| The policy control plane becomes unreachable while the gateway is already running | It denies the request rather than letting it through unchecked | The call is refused with a clear error instead of being allowed through without a policy check |
| A configured LLM provider is unreachable | The failure is reported back on that call only; the platform's own health is unaffected | That call fails with a clear error while the rest of the service keeps working |
| A rate limit on outgoing work reaches its configured cap | New work is throttled rather than dropped or silently discarded | New requests are held back instead of lost |
| The rate limit on outgoing work cannot be checked | New work is denied rather than admitted without a limit | The request is refused rather than silently let through uncapped |
| Confirmation of a protected action's outcome is slow to arrive, or never arrives | It retries on a bounded schedule, then records the outcome as unresolved rather than assuming success or failure | After a bounded wait, the action's outcome shows as unresolved instead of being silently marked successful |
Everything a security review asks for, on one page
Control status, hosting and data location, attestations, and the security contact.