Summary: A security buyer needs to know which action an agent can take, where it can be stopped, and what evidence remains afterward. Model behavior alone does not answer those questions. The APort decision-versus-enforcement contract makes the distinction explicit: the verifier evaluates the proposed action; the runtime determines whether a denial blocks execution.
Use the tool call as the starting point for an inventory. From there, follow the path to the filesystem, remote service, repository or payment processor. This guide connects those boundaries to the relevant setup and evidence, rather than treating every agent as the same deployment.
Find the boundary that owns the side effect
| Agent action | First investigation | What still needs a separate control |
|---|---|---|
| Read a file or run a command | Claude Code hook test | Filesystem isolation, subprocess behavior and editable settings |
| Use a coding editor's tools | Cursor security guide | That editor's active hook registration and credential scope |
| Invoke an MCP tool | MCP server and tool scoping | Transport authorization, resource permissions and argument validation |
| Change repository policy or CI | GitHub protected-path review | Required branch checks and direct-push restrictions |
| Fetch a URL | DNS and SSRF boundary | DNS resolution, redirects and the actual connection |
| Propose a payment | Payment authorization evidence | Processor controls and production acceptance tests |
A shared OAP decision shape helps teams compare policy results across integrations. Each runtime still needs its own coverage test. Installing one adapter does not create an enforcement point in another product.
Work backward from one prohibited outcome
Suppose an agent must never export a private dataset to an external destination. Start with the service that can send the data. Identify its API, command-line client and any MCP wrapper. Restrict credentials and network access at those boundaries, then decide which proposed-call parameters the policy must inspect.
This exercise often finds paths a prompt-level rule cannot cover. It may also find that the existing service already enforces the required restriction. In that case, validate that control rather than duplicating it solely to add an agent label.
The identity comparison helps distinguish delegated access, workload identity and action policy. Retain controls that already do their job.
Ask for three records from a test run
For a proposed action, capture the identity and policy context submitted to the verifier, the policy result, and the runtime outcome. Use decision_id to join hosted evidence where available. Keep secrets and full customer records out of that context.
A deny followed by continued execution in warn mode is an intentional rollout configuration, not proof of blocking. An allow followed by a failed tool is not a successful operation. An absent runtime report means the outcome remains unknown.
For owned experimental evidence, the Vault research page distinguishes payment requests, policy decisions and executed transfers. Apply the same separation when defining your own acceptance metrics.
An example inventory for a repository assistant
A repository assistant can reach the same resource through several paths. The following is a review template, not an assertion that all these paths are installed:
| Path to inspect | Prohibited fixture | Owner of the restriction |
|---|---|---|
| Direct file tool | Read a synthetic secret file | Host hook and filesystem permissions |
| Shell command | Read the same file through an interpreter | Process isolation and command policy |
| MCP file service | Read a resource outside the allowed project | MCP service permissions plus connected tool scope |
| Repository push | Write directly to a protected test branch | GitHub branch rules and bypass configuration |
| Web-fetch client | Follow a redirect to a prohibited test destination | Trusted network enforcement |
If one path is unneeded, removing its capability is easier to reason about than relying on a prompt to avoid it. If two paths are required, test both. Reusing the same passport vocabulary does not prove the two implementations share the same checks.
Attach each result to the installed version and configuration. A new plugin, command interpreter or credential can create another path even when the model and system prompt are unchanged. Use that inventory change as the trigger for a new coverage review.
Turn the inventory into a bounded rollout
Choose one workflow with an owner, a permitted fixture and a forbidden fixture. Verify enforcement in a disposable environment, including the failure path when authorization is unavailable. Expand only after the observed tool result agrees with the chosen enforcement mode.
Install my guardrail at the first runtime boundary in that inventory.