Short answers.

It identifies each agent, authorizes each tool call, records the decision, and holds calls that need a person for approval. The full picture is on the gateway page.

Agentic AI Security Gateway: the control point for tool calls explicitly routed through it. It identifies the caller, authorizes the call against policy, records the decision, and holds high-risk calls for a person. The full crossing is on the gateway page.

The gateway is designed to sit between agents and their tools. Each integration needs a path that routes calls through it. See the architecture page for compatibility scope and the implemented SDK and MCP paths.

The integrated executor stops the call. Policy priority and rule ordering apply; deny wins among contributing matches at the deciding priority. A denial is recorded and can still be returned if receipt signing fails. How decisions are made is on the policy page.

Six outcomes: allow (the call runs), deny (the call is stopped), redact (sensitive fields are masked), require_approval (a person decides), log_only (the call runs, flagged for review), or escalate (an escalated approval hold). Priority and first-match ordering apply before same-priority deny precedence. Worked examples are on the policy page.

In a human-in-the-loop inbox for high-risk calls. The gate holds the call until a person releases or refuses it, and the reviewer's decision is recorded too. Builders inherit this path; see who it is for.

When one agent calls another, the second acts with a scope no wider than the first, inside a chain with a bounded depth. Labels on sensitive data travel along and cannot be stripped by a later hop. The implemented mechanics and their limits are on the multi-agent page.

Dry-run tests a saved policy against a supplied context without tool execution. Replay compares a bounded historical sample and reports context reconstruction limits. These previews are available before enforce; promotion does not require that they were run. The worked preview is on the policy page.

The repository contains local and hosted deployment configuration and implemented onboarding. Actual service availability and data location depend on the deployment. The integration boundaries are on the architecture page.

The gateway focuses on routed agent actions: identity, policy, record, and approval. Studio separately implements provider conversations and text privacy; Discovery supplies inventory evidence. The category boundaries are on the trust page.

Receipts are signed records verifiable offline with the project verifier. What the receipt proves is on the evidence page.

A valid signature binds the agent, tenant, tool-call ID, verdict, timestamp, and nonce to a trusted key. The current strict-audit format also names its audit event. A proof bundle checks that binding and inclusion under a signed checkpoint; it does not authenticate all adjacent request or policy metadata. A receipt records a decision; it does not by itself prove that an external tool completed the action. The fields and checks are on the evidence page.

Every figure on this site comes from a published source. Each evidence card links its primary source and shows the date it was retrieved — see the home page cards. We publish no invented metrics of our own.