ActPass × the OWASP Top 10 for Agentic Applications (2026)

The preflight engine flags when a proposed action is sourced from untrusted content (web page, email, tool output) and requires human approval before it runs. The user’s goal is a signed passport claim, so injected content cannot silently redirect the agent’s objective.

In ActPass: preflight.ts (isActionOpenDelegation, policy.action_open_delegation) · passport.ts (signed goal claim)

Every tool call is checked against a deterministic policy and the passport’s signed allowed_tools scope. A tool outside the grant is denied (403) before execution — the scope is in the signed token and cannot be forged by the agent.

In ActPass: preflight.ts (evaluatePolicy, assertPassportUsable) · policy.ts · passport.ts (allowed_tools)

Action Passports are short-lived (TTL-clamped), single-use (replay-detected via jti), and RBAC-gated. Raw credentials never reach the agent — they are resolved only inside the broker on the execution path, so a cached or inherited token cannot be reused.

In ActPass: passport.ts + passport-ttl.ts · rbac.ts (assertPermission) · credentials.ts (executeWithBinding)

Tool manifests are hashed and diffed, and a poisoned descriptor (injection markers, homoglyphs, unverified publisher) fails the CI scan against a committed lockfile baseline. At use-time a deterministic identity gate re-hashes the descriptor the upstream actually served and requires it to equal the approved baseline (runtime body-tamper detection), and verifies a detached Ed25519 publisher signature against the tenant trust store — cryptographic proof replacing the self-asserted publisherVerified flag.

In ActPass: manifests.ts (drift) · scanner.ts (poisoning) · tool-identity.ts (descriptor pin + publisher sig) · publisher-trust-store.ts · preflight.ts (use-time gate)

Shared responsibility: Signature verification is cryptographic, but bootstrapping the trust store (binding a key to a real-world publisher, distribution/rotation) is out-of-band key management; the descriptor pin covers calls routed through ActPass that present the served descriptor — direct-to-upstream paths and runtime behaviour tampering still need inline proxy placement plus sandboxing.

Coding-agent PreToolUse hooks and policies gate Bash/shell/execute calls by their arguments, and the Rule of Two blocks capability combinations that enable exfiltration. A deterministic preflight gate additionally requires approval for any execute-category tool whose command was sourced from untrusted content — so an injected command can no longer pass on benign-looking args.

In ActPass: coloring.ts (classesForToolCall) · preflight.ts (provenance-aware exec gate, UNTRUSTED_ACTION_SOURCES) · packages/cli hook

Shared responsibility: The gate keys off the caller-supplied action_source — the same signed-claim provenance model ASI01 relies on; ActPass enforces at the execution boundary, it does not control the model’s code generation.

Capability “colors” accumulate across a session; once an agent holds untrusted-input + sensitive-access + external-comms, the next exfiltrating action is blocked (runtime Rule of Two). Memory/RAG records are also integrity-bound: each is provenance-tagged and AES-256-GCM sealed with AAD bound to its identity on write, and verified on read — a tampered, row-swapped, or untrusted-sourced record is detected and quarantined before the agent consumes it.

In ActPass: coloring.ts (evaluateColoring) · memory-integrity.ts (commit / verify / quarantine) · crypto-envelope.ts (AAD-bound GCM)

Shared responsibility: ActPass provides the integrity primitive; a host must route its memory/RAG writes through commitMemory and reads through verifyMemory — records written by code paths that bypass it cannot be retrofitted.

Passports are audience-scoped per delegation; a passport presented to the wrong service fails (403). Forwarded inter-agent / proxy calls also carry a detached Ed25519 signature over the canonical request (method, path, audience, body hash), verifiable by the peer against ActPass’s published JWKS, and egress is forced to TLS-only, non-private ranges — so a tampered, mis-routed, or cleartext call is detectable and blocked.

In ActPass: passport.ts (audience binding) · request-signature.ts (sign / verify) · http-forward.ts (https-only egress) · app/proxy (fail-closed)

Shared responsibility: This is application-layer message integrity + origin proof, not transport-layer mutual TLS — peer-certificate pinning (true mTLS) still needs certificate infrastructure, and the peer must actually verify the signature.

Per-tenant rate limits (429), kill switches, and a strict-mode signal on SLO breach bound runaway loops; the engine fails closed on evidence and policy errors. Rate limits are durable — atomic Postgres counters that survive restarts and are shared across replicas — and an automatic circuit breaker trips a tool to a fail-closed deny once its failure rate crosses a threshold, instead of merely recommending a mode.

In ActPass: durable-limits.ts (enforceDurableRateLimit / recordOutcome / breakerTripped) · preflight.ts (breaker gate, fail-closed) · runtime-control.ts (kill switch)

Shared responsibility: Fixed-window counters reset sharply at boundaries (a straddling burst can briefly exceed the cap); true smoothing needs a sliding / token-bucket window.

Human approvals are cryptographically bound to the exact action payload (a request hash over tool + resource + canonicalized args). Mutate the payload and the approval no longer matches — a reviewer cannot be tricked into approving a different action than executes. An FSM prevents approval state races.

In ActPass: preflight.ts (request hash, approval.satisfied) · passport.ts (approval_hash verify, fail-closed) · approvals-fsm.ts

Passports are revocable (checked at verification and again just-before-use), the evidence chain is tamper-evident (hash-linked), and the proxy is deny-by-default — any non-allow decision is never forwarded upstream.

In ActPass: passport.ts (revocation) · evidence-store.ts / evidence.ts (hash chain) · app/proxy (fail-closed)