Single tenant, no cross-customer amplification
The control plane in your data centre serves only you. Cross-tenant credential leakage does not exist as a threat class because there is no second tenant. It also simplifies the architecture materially.
Threat model & boundaries
What we can do, what we cannot,
and what we have not worked out
A security document that lists only strengths is a negative signal to a CISO. This page is deliberately inverted: the risks we introduce first, the problems we solve second, and the questions we have no answer to at the end.
Threat #0
AgentPAM holds the keys to every sensitive API
The thing to face honestly firstCentralizing credential custody means this control plane becomes a new high-value target itself. The industry has already run this experiment once: one compromised intermediary equals every downstream system compromised. Any claim that centralizing credentials has only upside is incomplete.
Private deployment changes the shape of this threat but does not remove it. Because the control plane runs inside your own network and is single-tenant, the SaaS-specific amplification of “one breach reaches every customer” does not exist — the blast radius is bounded by your own perimeter. Inside that perimeter, it is still one of the highest-privilege components you run.
Root keys in your HSM
Signing and wrapping keys never leave the hardware security module in plaintext. Holding root keys in your own KMS / HSM over PKCS#11 must be supported; a software-key mode is explicitly labelled as a lower assurance tier.
Can the broker itself be blind to the credential?
Is a zero-knowledge credential design possible — where the broker cannot read the plaintext even as it injects it? We do not have a satisfying answer yet.
Threat classes
Threat classes and where we stand
Every row below is marked with its current status: Designed / Needs dedicated work / Explicitly cannot.
| Class | Key question | Where we stand | Status |
|---|---|---|---|
| Control plane compromised | the broker is breached = every credential it holds leaks | Single-tenant private deployment bounds the blast radius to your own perimeter (no cross-customer amplification); root keys held in your KMS / HSM; zero-knowledge credential design still unsolved. | Needs dedicated work |
| Clock drift defeats short TTLs | without external NTP, a 60–300s Tup may expire on issue | Detect cluster clock skew at startup and warn; define an explicit tolerance window; fail closed with an explicit error when skew exceeds the threshold — never silently allow. | Designed |
| Agent self-tampering | the agent rewrites its own gate scripts (publicly documented) | Any control the agent can edit is not a control. Only root-owned managed policy, or an out-of-process broker, survives. This is one reason the credential sits outside the agent process. | Designed |
| Prompt injection → authorized call | a hijacked agent makes a call it is entitled to make | We cannot stop it. We degrade the impact, record it, and make it revocable. See the next section. | Explicitly cannot |
| Rug pull (tool description changed) | approve-at-install with no re-verification is the norm, and the gap has been exploited (CVE-2025-54136) | Tool description pinning (TOFU) + forced re-authorization on change | Designed |
| Availability is security | we go down, every agent stops | Fail-open violates deny-by-default; fail-closed makes us a single point of failure. A break-glass mechanism has to be designed, not avoided. | Needs dedicated work |
| Unregistered agents | an agent not in the registry makes a call — now what? | Refusing impedes adoption; allowing leaves a hole. This is a policy question we have not settled. | Needs dedicated work |
Prompt injection
We do not prevent prompt injection. We change its consequences.
This sentence is worth stating precisely, because the market is full of the opposite over-promise. Prompt injection is a confused deputy problem: anything the agent reads may be attacker-authored instructions, and the agent holds real privilege. When a hijacked agent makes a call it was already entitled to make, no control sitting above the credential — dialogs, tool-description validation, intent classifiers — can determine in principle that the call should not happen.
Degrade
The credential's scope is narrowed to this one specific operation and its lifetime is measured in seconds. What would have been “exfiltrate the entire private repository” degrades to “make one authorized call.”
Record
The call is attributable to a named human + agent instance + task and written to a tamper-evident audit record. Afterwards you can actually establish what happened.
Revoke
Consume CAEP / Shared Signals events from your IdP to kill an in-flight agent session within one token TTL; or use token-claims-change to narrow a running agent's privileges rather than only killing it.
One more honest limitationOnce an SVID or credential has been issued, many designs trust that workload for its whole validity period regardless of what it did afterwards — an agent prompt-injected at minute 3 still holds the valid credential issued at minute 0. That is exactly why we insist on short TTLs and per-call PDP checks. But note what that buys: it shortens the exposure window, it does not close it to zero.
Compliance
Compliance mapping
The standards below share one requirement: every privileged action must be attributable to a named, unique, non-shared identity, and the record must be tamper-evident and retained. A static API key structurally cannot satisfy that — and this gap holds today, without waiting for any new regulation.
| Standard | Clause | Evidence we provide |
|---|---|---|
| SOC 2 | CC6.1 / CC6.3 / CC6.5 / CC6.6 / CC7.2 | Every privileged action attributable to a named, unique, non-shared identity; logical access granted and revoked on least privilege. This is our core argument. |
| DORA | Chapter II — ICT risk management | Access control and traceability over ICT assets for financial entities. Financial services is currently the one segment with live obligations. |
| PCI DSS 4.0 | Req.7 / Req.8 / Req.10 | Unique IDs, no shared accounts, 12-month log retention. |
| ISO 27001:2022 | A.8.2 / A.8.15 | Management of privileged access rights; logging. |
| NIS2 | Art.21(2) | Access control as a baseline cybersecurity risk-management measure. |
The sentence we will not say“The EU AI Act mandates logging of AI agent privileged actions.” That is a misreading of the regulation and we will not say it in any external material. Article 12 binds providers of high-risk AI systems, and the applicability of the high-risk obligations has been deferred. Driving a purchase with a misread regulation gets caught on the spot by a mature GRC buyer — and that would destroy the credibility of everything else on this page. Every row in the table above is already in force today; we do not need to borrow a new regulation.
Open questions
Questions we have no answer to
We keep this list on a public website because it is the biggest difference between us and a demo-driven product.
- Testing the gateway compatibility matrix
- Only one path is verified end to end today; everything else is marked not yet tested. Priority: CRITICAL.
- A complete threat model
- This page is an outline, not a finished threat model. Control-plane compromise, break-glass, and zero-knowledge credential design are all still open. Priority: CRITICAL.
- Whether per-tool authorization breaks developer experience
- The target is P99 < 200ms. If we miss it, developers will find ways around us, and then no amount of architectural correctness matters.
- What to do about unregistered agents
- Refusing impedes adoption; allowing leaves a hole. Unsettled.
- The ideal customer profile is not validated with real buyers
- The working assumption is “EU-exposed financial services / fintech, 1,000–10,000 employees,” which comes from desk research and has not been validated through enough real buyer interviews.
On the factual basis of this siteThe arguments here rest on structural facts: published protocol specifications (RFCs, the MCP authorization spec, OIDF drafts), publicly disclosed security incidents, and verifiable compliance clauses. We have deliberately not cited competitors' funding, acquisition prices, or GA dates anywhere on this site — we cannot vouch for the currency or accuracy of that class of information here. Third-party survey figures are attributed; verify them before citing.