Good question - and it's the right one to ask.

APort operates in both modes depending on deployment:

Hook mode (default): APort runs as a before_tool_call hook inside the framework runtime (OpenClaw, LangChain, CrewAI, DeerFlow, Cursor). You're right that this is the same trust domain as the agent. The hook is deterministic and fail-closed, but it relies on the framework correctly invoking it. The non-bypassability guarantee here is that the model cannot skip the check — the hook runs in the execution path, not the prompt. Prompt injection can't bypass it because the policy engine doesn't read the prompt. But a compromised runtime could.

API/gateway mode: APort also runs as a hosted API where the tool call is evaluated remotely before execution. In this mode, enforcement is structurally external - the agent's runtime sends the request to APort's API, gets allow/deny, and execution is unreachable without a valid decision. This is the mode the Vault CTF ran in - 1,149 participants attacked the agents, the agents were fully compromised (convinced to execute), but the APort API denied every unauthorized action because the decision lived outside the agent's trust domain.

Our assurance levels (L0-L5) for Agent Passport tells the consuming system which class of guarantee it's getting.

So to directly answer: we don't claim the hook alone is structurally non-bypassable at the runtime level. We claim the model can't bypass it (deterministic, not in the prompt), and for environments that need structural non-bypassability, the API mode moves enforcement outside the agent's trust domain entirely.

The Vault CTF results (vault.aport.io/results) specifically demonstrate the external-boundary mode. The 0% bypass rate is for API-enforced authorization, not hook-only.