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.

Yes. The gateway ships as a Docker image with a Helm chart and Terraform module, plus /api/health and /api/health/ready probes. You bring Postgres and your signing keys; everything else is config. The same OpenAPI contract applies hosted or self-hosted, so you can switch later.

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, self-host support). 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.