Protect the execution boundary

Suppose you protect a refund tool with AuthRail, but the agent can also read the Stripe credential and make a refund directly. The protected tool can stop a request; the direct route remains open.

An execution boundary is the point where your application performs the real operation. AuthRail's SDK must check that point, while the application keeps the credentials needed to execute it. This page helps the application developer check that the agent has no other route to the same effect.

Do this review before relying on Enforce, and repeat the affected checks when you add tools or change access to files, credentials or networks.

Review one protected operation

Choose a concrete operation, such as sending a support reply or refunding a payment. Then work through its actual routes:

1. List everything that can perform it. Include other tools, direct API calls, shell commands and work delegated to another agent.
2. Check where its credentials live. The agent must not be able to read them through files, prompts, process settings, browser code or tool results.
3. Check the SDK placement. The real business function must go through the required decision and execution steps before it runs in Enforce.
4. Check who and what the request belongs to. Obtain the signed-in user or workload identity, resource and provider account from trusted application code. An agent-written argument must not switch those identities or accounts.
5. Try a denied request and an unavailable check in a safe system. Inspect the application's saved effect record or provider account to establish that the protected function did not execute.
6. Try the alternative routes you listed. Each must use the required checks or be unavailable to the agent.

Expected result: the team can show where the action is checked and why the agent cannot perform the same action elsewhere. Record any uncovered routes and treat their access as advisory. A running sidecar alone cannot establish protection for every tool.

More about who holds each credential

Credential	Holder	Purpose
Deployment token	Sidecar.	Connect this deployment to AuthRail.
Adapter token	Protected application and sidecar.	Authenticate local SDK requests.
Executor private key	Protected application.	Sign the application's identity, input and outcome reports.
Provider credential	Protected application.	Perform the business operation.
Operator token	Authorised operator.	Review local recording gaps.

The sidecar verifies requests using the executor's public key. Keep the private key and provider credential with the protected application, outside the agent's reach. The sidecar is not a store for credentials the agent can request.

A discovery key helps set up an application. It does not grant permission to execute a protected operation. A signature establishes an assertion from the registered key; it does not independently establish provider completion or which model generated the original request.

Keep the local rule checker private

The sidecar runs beside the protected application on the customer's system. Its listener uses loopback, the local network address available on that machine. The SDK also authenticates with the adapter token, because a local address alone does not authenticate another process.

For Docker, follow the application placement instructions instead of publishing the decision port. Keep one configured decision process for its deployment; do not expose it as a public service or share it between unrelated deployments.

Review information before sending it

Result checks can stop sensitive output from reaching the agent. They happen after the business function, so they cannot undo an earlier provider operation or model call.

AuthRail's contextual AI feature sends selected material to the configured model provider so it can answer the reviewed question. Choose the permitted fields and perform any required removal or redaction in trusted application code before that call. The contextual AI guide explains who receives the text and what AuthRail retains.

Add a sandbox where your application needs one

A sandbox restricts the files, commands and networks an agent can use. The NVIDIA OpenShell integration keeps the protected application and sidecar outside the agent's sandbox.

Review the policy actually loaded by the sandbox and test the credential, file and network routes above. A policy template describes intended restrictions; verify those restrictions in the running installation before relying on them.