Frequently Asked Questions

No — and that's the point. Prompt filters ask a model to police a model; they're probabilistic and bypassable. ActPass makes the decision outside the LLM with a deterministic rules engine: the same action under the same policy gets the same decision, every time, with the matched rules returned. A prompt injection can change what your agent wantsto do; it can't change what ActPass lets it do.

allow, deny, require_approval (pause for a human), require_tool_reapproval (the tool changed since you approved it), or warn in warn mode. Each carries a stable typed reason code you can alert and branch on.

No. Three adoption levels: (1) the MCP proxy or REST proxy enforce with zero agent changes — only config changes; (2) the SDK wraps individual actions with guard() in a few lines; (3) the raw API for everything else. Most teams start with the proxy in monitor mode.

Anything that calls tools over MCP or HTTP — Claude/MCP agents, LangChain, LlamaIndex, OpenAI tool-calling, custom orchestrators, and n8n workflows via our node. The enforcement boundary is the tool call, not the framework, so framework churn doesn't affect your policies.

The decision itself is sub-millisecond — it's a pure rules evaluation, no model inference. End-to-end you pay one HTTPS round trip to the gateway (typically 20–80 ms region-dependent). For high-risk actions like refunds and deploys, that's noise; for hot read-only paths, scope your policy so cheap reads are allow-listed or left ungated.

In enforce/strict mode the system fails closed: SDK guard() reports blocked, the proxies return BLOCKED, and the action does not run. We treat "unreachable" the same as "unauthorized" — a security gateway that fails open is theater. If availability matters more than enforcement for a given workload, run it in monitor mode, where decisions are logged but never block.

Yes — send an idempotency_key. Retrying the same key and payload returns the original decision instead of double-counting or burning a passport's single use. A retry with a different payload under the same passport is flagged as passport.replay_detected.

Not by talking its way out. Decisions are server-side; tenant IDs, approval hashes, and manifest hashes from the client are never trusted — they're re-verified against our ledgers. Passports are EdDSA-signed and single-use, so they can't be forged or replayed. The honest residual risk: if your agent holds the upstream API key directly, it can skip the proxy entirely — which is why the credential vault exists. Vault the key, bind it to the gateway, and the agent never possesses anything worth stealing.

Keys are rotatable with overlap: add a new signing key, keep the retired public key in the verification set until issued passports expire (minutes, not months), and revoke anything suspicious by jti — revocation is durable across all gateway replicas. Evidence-report signing uses a separate key from passport signing.

Everything is tenant-scoped at the query layer with RBAC (8 roles × 17 permissions) on top. Vaulted credentials are AES-256-GCM envelope-encrypted and write-only — no API returns a stored secret. Sensitive action arguments are redacted before persistence (configurable: metadata-only, redacted payload, or full payload). Audit tables are append-only at the database level.

That's what the hash chain is for. Each evidence event links to the previous event's hash, and exports are Ed25519-signed. GET /v1/evidence/verify recomputes the chain from the sealed canonical events — you (or your auditor) can independently confirm nothing was edited after the fact, including by us.

Week 1: proxy or SDK in monitor mode — nothing blocks, you see every action your agents take. Week 2: turn on a policy pack, review what would have been blocked, fix false positives in the Policy Manager. Week 3: flip to enforce for your riskiest tools first (payments, deploys, outbound email), then expand. strict mode adds mandatory passports for high/critical-risk tools.

Anyone with the approval.decide permission — owners, admins, security admins, and designated approvers — from the dashboard or Slack. Members are read-only. Pending approvals auto-expire after your SLA window (default 24h), so nothing hangs forever; expiry is itself an audited event.

No — ActPass is a managed service at www.api.actpass.org. That is what keeps the enforcement surface, signing keys, and evidence ledger uniformly patched and auditable. Your policies and evidence remain exportable at any time (see “Am I locked in?” below).

Your policies are portable JSON you can export at any time, evidence exports to standard formats (JSON, CSV, SIEM-JSONL), and the enforcement surface is a documented OpenAPI contract. Removing ActPass is a config change — agents point back at their upstreams. We'd rather keep you with the product than with switching costs.

Both frameworks expect demonstrable human oversight, risk-based controls, and audit trails for AI systems. ActPass produces exactly that artifact set: deterministic policies (documented control), approval workflows (human oversight), drift re-consent (change management), and signed, tamper-evident evidence bundles (auditability). The built-in compliance engine continuously evaluates these controls against live system state via GET /v1/compliance.

Yes — enterprise SSO via OIDC with full id_token verification (signature against the IdP's JWKS, issuer, audience, expiry, nonce) and just-in-time user provisioning. Unverified email claims are refused outright.

Free for individual developers attesting a single agent; paid tiers add scanned reports, active passports, team seats, and enterprise features (SSO, SIEM, custom retention). See pricing for current numbers — no enforcement feature is paywalled into unsafety.

Email security@actpass.org— coordinated disclosure, 48-hour acknowledgement. Please don't open public issues for vulnerabilities. Our full policy is in SECURITY.md in the repository.