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 |
| Attestation degraded when air-gapped | Apple notarization cannot be checked online — does attestation strength drop? | Yes, it drops. Offline we can only do local static signature verification plus stapled tickets. The product labels which tier the attestation is in; we do not present the two tiers as equivalent. | Designed |
| 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, per-call PDP checks, and continuous re-attestation. But note what that buys: it shortens the exposure window, it does not close it to zero.
Local process attestation
There is no usable root of trust on a laptop
This is the hardest technical bone in the product. We label it heuristic and defense in depth, and never claim it is equivalent to hardware remote attestation.
| Off-the-shelf approach | Why it does not hold for a macOS CLI process |
|---|---|
| SPIFFE workload attestation | Collapses here into UID + binary path, which a user can trivially forge. It gives you a name, not a guarantee. |
| Apple App Attest | An iOS / iPadOS / tvOS API that does not support arbitrary macOS CLI processes. |
| TPM 2.0 | Essentially nonexistent on macOS. |
| WebAuthn / FIDO2 | Binds “human to device,” not a background process. |
| TEE remote attestation | A server-side technology; not applicable to a developer laptop. |
Local process attestationAir-gapped environments drop another tier. Apple's online notarization check is unavailable without outbound access, so the offline path is reduced to local static signature verification (Team ID, signing chain, hardened runtime flag) plus stapled-ticket validation. The product labels which tier the current attestation is in — we do not present the connected tier and the air-gapped tier as the same thing.
attestation_score = f( code signature + notarization // Team ID, hardened runtime. // Verified by a local privileged helper -- // a process cannot attest itself. , Secure Enclave device key // non-exportable; binds device posture at enrollment , MDM enrollment state // when available, the strongest claim about this machine , parent process chain // was this MCP server launched by Claude Code, or something else? , continuous re-attestation // re-verified mid-session, not once at issuance ) This is a composite heuristic. It raises the cost of impersonation. It is NOT a hardware root of trust, and we will not describe it as one. Air-gapped tier: no online notarization check. Falls back to local static signature verification + stapled ticket. Explicitly a WEAKER tier -- labelled as such in the product, never presented as equivalent.
Continuous re-attestation
A workload identity issued once is trusted for its whole validity period no matter what the workload does afterwards. The prompt-injection threat model requires mid-session re-verification — that is the substantive difference between us and one-shot attestation.
Attesting yourself is logically void
Storing a non-exportable key in the Secure Enclave requires our own code-signing identity; proving who the calling process is makes no sense if the SDK runs inside the process being attested; and the credential has to be held outside the agent process — the physical precondition for “credentials never land.” So the Local Attestor has to be a separate, code-signed daemon.
Deployment constraint · C-09Every customer-side V1 component must be pure userspace: a single binary that runs without kernel extensions, MDM push, or special platform entitlements. Enforcement layers that need those are deferred to V2 Enterprise — because developers will not self-install a kernel extension that needs security-team approval, and developers are the first users.
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.
- Bypass cost of macOS local process attestation
- How much does the composite heuristic actually raise the cost of forgery? We need a quantifiable, publishable number, not “hard to forge.” Priority: CRITICAL.
- How far apart the air-gapped and connected attestation tiers are
- Both tiers need a quantified forgery cost rather than a vague “weaker when air-gapped.” Bound to the item above; equally CRITICAL. Priority: CRITICAL.
- 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.