Security
ActPass is a control plane that sits between AI agents and the tools they call. Its job is to keep risky actions from executing, so security is the product — not a bolt-on. Here is exactly how it works and what we do and do not claim.
Deterministic, fail-closed enforcement
Every action runs through a deterministic policy evaluator: the same input always yields the same allow / deny / needs-approval decision. Network errors, missing keys, and unverifiable claims always deny — never fail open.
Action Passports (EdDSA)
Actions are authorized by short-lived, goal-scoped Ed25519 (EdDSA) credentials with single-use replay defense and key rotation. Signatures are always verified server-side; client-supplied tenant, tool-hash, and approval fields are treated as hints and independently re-verified.
Encrypted credential vault
Downstream secrets are envelope-encrypted with AES-256-GCM and bound to a scoped, time-limited credential at execution. The broker refuses to store secrets without a configured encryption key.
Tamper-evident evidence chain
Each decision is sealed into an append-only, SHA-256 hash-chained ledger. Reordering or editing any event breaks the chain, and the chain can be independently verified. Exports are signed.
Tenant isolation
The tenant is always resolved from the authenticated principal, never from the request body. One tenant can never read, release, or approve another tenant’s actions.
Threat model & honest limitations
Every call that reaches ActPass is enforced: the proxy resolves the upstream from server-side config (never client input), binds credentials from the encrypted vault, and fails closed on any non-allow decision. The limits we state plainly rather than bury:
- Network egress control is the load-bearing requirement. The gateway is a mandatory chokepoint only if the agent host cannot reach the upstream directly. Strip ambient credentials from the agent runtime and allow egress only to the ActPass proxy — otherwise a leaked token can route around it. This is a deployment property (firewall / NetworkPolicy / VPC egress rule), not something repository code can guarantee.
- Reads are not gated, by design. To keep latency off the read path, ActPass gates state-changing and outbound actions, not reads — so data exfiltration through read APIs needs a separate response-filtering layer.
- Every ungated tool surface is a hole. A second, ungated MCP server or a tool carrying its own token is a parallel path ActPass never sees. Inventory and route every tool surface through the gateway.
Compliance status — stated honestly
ActPass is not currently SOC 2, ISO 27001, or HIPAA certified, and we do not display badges for certifications we do not hold. A SOC 2 Type II program is on our roadmap. The architecture above — deterministic decisions, signed passports, an encrypted vault, and a hash-chained evidence ledger — is designed to produce the audit evidence such a program requires. Design partners can request our current security documentation directly.
Security documentation & trust artifacts
- OWASP Top 10 for Agentic Applications (2026) → ActPass control mappingCode-grounded, with honest per-risk coverage (all 10 addressed at the action boundary, shared-responsibility notes where infra applies).
- Software Bill of Materials (CycloneDX)Full dependency inventory, regenerated with
npm run sbom. - Security policy, scope & design guaranteesReporting process, in-scope surfaces, and the invariants we defend.
Responsible disclosure
Found a vulnerability? Email security@actpass.org. We aim to acknowledge reports within two business days. Please give us a reasonable window to remediate before any public disclosure.
See also our Privacy Policy, Terms, and Data Processing Addendum.