Agent Runtime Gate

1. Runtime gate overview

   Agent Runtime Gate sits between your agent and its tools. It verifies packages, checks policies, and decides whether an action is allowed to run, before anything executes.

   Pre-execution verification Verify artifacts, attestations, vulnerabilities, and provenance before execution.

   Policy enforcement Apply organization policies and risk thresholds to every agent action.

   Auditable decisions Record every decision with tamper-evident logs and attestations.

2. Install

   Add the runtime gate SDK to your agent runtime.

   npm install @phyi/runtime-gate

3. Wrap an action

   Check with the gate before executing a tool or arbitrary action.

   import { RuntimeGate } from '@phyi/runtime-gate';
   
   const gate = new RuntimeGate({ apiKey: process.env.PHYLAX_API_KEY });
   
   async function runTool(tool: Tool, input: any) {
     const decision = await gate.check({ tool, input });
   
     if (decision.decision === 'block') {
       throw new Error(`Blocked by policy: ${decision.reason}`);
     }
     return await tool.execute(input);
   }

4. Policy decisions

   The gate returns a decision you can act on.

   ALLOW The action is permitted. Safe to execute.

   WARN Proceed with caution. Review the reason and context.

   BLOCK The action is denied. Do not execute.

5. Logging and attestations

   Every decision includes rich context and an attestation reference.

   {
     "decision": "allow",
     "reason": "No policy violations",
     "riskScore": 18,
     "policies": ["package.verified", "vuln.none", "license.allowed"],
     "artifact": "pkg:npm/express@4.18.2",
     "attestationId": "att_8f3c2e1a6b0d04a7c8a1b2f3d4e5f8a7b",
     "timestamp": "2026-05-19T10:21:35Z"
   }

6. Best practices

   • Define least-privilege policies and review them regularly.
   • Prefer blocking on unknown or high-risk changes.
   • Cache decisions briefly to reduce latency, but avoid long-lived allow caches.
   • Log all gate decisions and monitor for spikes in warnings or blocks.
   • Keep the gate SDK updated to benefit from new checks and policies.

Decide what happens when the gate is unreachable

This is the decision that matters most, and it is the one most gates get wrong by not making it explicitly. The gate is inline with execution, so a network partition or an expired key becomes an availability question at the worst possible moment.

Mode	On error	Use when
Fail closed	Treat as BLOCK	The agent can take real-world actions: writes, payments, deploys, outbound mail
Fail open	Treat as ALLOW, log loudly	The agent is read-only and an outage would break something a human is waiting on

Pick per tool, not per application. The same agent can fail closed on filesystem.write and fail open on search.query. Whichever you choose, emit a distinct decision reason so an outage never looks like a clean ALLOW in your audit trail.

A cached allow is a policy decision with an expiry

Caching is how you keep the gate off the critical path, but a cached ALLOW means the agent is acting on a verdict that may already be stale. Keep allow caches to seconds, key them on the exact artifact version rather than the tool name, and never cache across a version change. Denials are safe to cache for longer.

Why a runtime gate and not just a build check

Build-time verification answers “was this dependency safe when we shipped”. An agent’s tool set is not fixed at build time: it discovers tools while it works, and a tool’s description is read as trusted context by the model. That is the tool poisoning problem described on the MCP Servers page, and it is the reason a check has to exist at the moment of execution rather than only in CI.

Concretely, the gate catches three things a build check cannot:

• A tool or server published or modified after your last build
• A tool whose definition changed after it was approved
• An action whose arguments violate policy, even when the tool itself is allowed

Keep the gate off the critical path

The gate runs on every action, so its latency is your agent’s latency.

• Check asynchronously where the action allows it, and await only before side effects.
• Batch the checks for a plan before executing it, rather than one round trip per step.
• Cache denials aggressively and allows briefly, as above.
• Set an explicit timeout, and make the timeout path the same as your fail mode. An unbounded await is a hang, not a security control.

Related guides

Verify the servers an agent connects to in MCP Servers, gate the build as well with CI/CD Pipelines, or read the verdict vocabulary in Core Concepts.

The gate is open source at praxi-labs/phylax-runtime-gate.