NIST AI RMF and OWASP agentic mapping

What the evidence supports

Gateway policies are written rules: allow, deny, or hold for approval. Every decision entry names the rule that produced it and whether the policy was enforcing or only observing, so a reviewer can see which declared control applied to each recorded tool call the gateway decided.

What it does not establish

That the rules reflect your organization’s risk priorities, or that the process is transparent to anyone beyond the people who read the log. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry.

Not covered

Your risk management process and its outcomes outside agent tool calls.

Ledger entries: policy.decision

What the evidence supports

The Agent Environment Review lists the AI agents, MCP servers and agent capabilities, such as shell, repository and database access, configured in the workspace it reviews.

What it does not establish

That the inventory is complete for your organization. It covers one workspace at a time, and only the agent configurations it recognises.

Not covered

Models, datasets and AI systems other than coding and workflow agents, and how the inventory is resourced.

What the evidence supports

Denied and held calls are recorded as distinct outcomes, which helps identify incidents at the agent tool layer. An exported evidence bundle can be given to another party, who can check it offline without access to your systems.

What it does not establish

That incidents outside the gateway’s view were identified, or that any information was actually shared. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. Whoever holds the signing key can rewrite and re-sign the record and it still checks out; only a tree head received before the change, or one with an independent timestamp (checked separately; this kit does not check timestamps), catches that; a bundle received earlier catches it only if the change left fewer entries, because a bundle is compared by count.

Not covered

AI testing practices and your information-sharing arrangements.

Ledger entries: policy.decision, gateway.tool_call

What the evidence supports

A rule can hold a tool call for approval: the gateway refuses the call and issues a single-use token, and a retry of the same call carrying that token is let through once an approval is on record. The ledger records the refusal, the approve step and the redemption of the token, each linked to the held call. Tokens are single use and expire.

What it does not establish

Who approved, or that anyone did. The approver label is recorded as a digest of whatever was supplied and is not authenticated, and a redeemed token does not by itself show that the approve step ran. The record shows the approval protocol was used, not that a particular person took the step or judged it well. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

How your oversight process is defined and assessed.

Ledger entries: gateway.tool_call, approval.granted, approval.consumed

What the evidence supports

The gateway pins each MCP tool’s name, description and input schema by hash when it first sees them. If a third-party server later changes them, the change is recorded and calls to that tool are refused until it is re-pinned.

What it does not establish

That a tool was safe when it was first pinned. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

Third-party models, datasets and software packages, and components other than MCP tool definitions.

Ledger entries: gateway.tool_pinned, gateway.tool_drift

What the evidence supports

While the ledger file reads cleanly, each tool call the gateway decides is recorded with its decision, and each forwarded call’s result is recorded as a digest with its error flag and latency.

What it does not establish

Behaviour the gateway does not decide, such as an agent’s built-in file or shell tools, leaves no entry. For a result streamed over HTTP, the error flag is always recorded as false. Nothing here measures the quality of the model’s output. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry.

Not covered

Model performance monitoring.

Ledger entries: gateway.tool_call, gateway.tool_result

What the evidence supports

The Agent Environment Review evaluates an agent setup: the tools, servers and access it holds, and configurations known to be risky, reported as findings.

What it does not establish

That the setup is secure. The review reports the patterns it knows; it does not test how the system holds up under attack.

Not covered

Penetration testing, and model robustness and resilience testing.

What the evidence supports

The ledger is hash-chained. When the gateway runs with a signing key, it signs each entry it writes, and a tree head over the ledger or an exported bundle can be signed too; without a key, entries are written unsigned and the checkers report them as unsigned, never as verified. With signatures, another party can check offline that no entry was changed, reordered or removed from the middle by anyone without the signing key. Against a tree head received earlier, they can also check that none of the entries it covers was cut off or rewritten, even by the key holder; against a bundle received earlier, only that at least as many entries remain, because a bundle is compared by count. The format, the checkers and a sample are public.

What it does not establish

That the record is complete or true, or who holds the signing key. Whoever holds it, usually the operator being assessed, can rewrite and re-sign the whole ledger and it will pass; only a tree head received before the rewrite, or one with an independent timestamp (checked separately; this kit does not check timestamps), catches that; a bundle received earlier catches it only if the rewrite left fewer entries, because a bundle is compared by count. Signing is off unless a key is supplied, and some entries are written without a signature, such as those a review run writes, so a ledger that holds them is reported as having an entry with no signature. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry.

Not covered

Your own examination of transparency and accountability risks.

Ledger entries: policy.decision

What the evidence supports

The gateway has a kill switch: while it is on, the gateway refuses the tool calls it decides. Turning it on and off with the command is recorded, and a drill records whether a test call was actually refused.

What it does not establish

That responsibilities for using it are assigned and understood, or that it was used when needed. It does not stop calls the gateway does not decide. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. Turning the switch on or off with the command is recorded; deleting the switch file turns it off with no entry, and the agent’s own user account can delete it. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry.

Not covered

Deactivating AI systems outside the gateway.

Ledger entries: gateway.killswitch, gateway.killswitch_drill

What the evidence supports

The ledger gives a dated sequence of allowed, denied and held calls, and of calls released by an approval token, that an incident record can cite, and an exported bundle lets someone else check that sequence offline.

What it does not establish

That anyone was told, or that the sequence is complete. The dates are the recorder’s own claim. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. Whoever holds the signing key can rewrite and re-sign the record and it still checks out; only a tree head received before the change, or one with an independent timestamp (checked separately; this kit does not check timestamps), catches that; a bundle received earlier catches it only if the change left fewer entries, because a bundle is compared by count. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

Communicating incidents, and running response and recovery.

Ledger entries: policy.decision, gateway.tool_call, approval.granted

What the evidence supports

When a manipulated agent attempts tool calls the gateway decides, each attempt is allowed, denied or held under your policy before it runs, and recorded while the ledger file reads cleanly.

What it does not establish

That a hijack happened or was stopped. The gateway does not read prompts or tool content; entries hold digests, not text. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry.

Not covered

Detecting prompt injection, and checking an agent’s goals or intent.

Ledger entries: policy.decision, gateway.tool_call

What the evidence supports

Tool calls the gateway decides are allowed, denied or held for approval before they reach the tool server, and each decision is recorded. The Agent Environment Review lists the MCP servers and capabilities an agent is configured with.

What it does not establish

That every tool call was checked: calls the gateway does not decide leave no entry. Arguments are recorded as a digest and are not inspected. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry.

Not covered

Inspecting tool arguments for secrets or harmful content, and usage budgets or rate limits.

Ledger entries: policy.decision, gateway.tool_call

What the evidence supports

Each decision records a digest of the agent identity the gateway was started with and the rule that matched, and rules can hold privileged tools for approval.

What it does not establish

Who the agent or the approver really is. Both identities are declared, not authenticated. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

Credential handling, token scoping and delegation chains.

Ledger entries: policy.decision, approval.granted

What the evidence supports

MCP tool definitions are pinned by hash on first sight. A later change by the server is recorded and the tool is refused until re-pinned. The Agent Environment Review lists the MCP servers an agent is configured to use.

What it does not establish

That a server or tool was trustworthy when first pinned. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

Package, model and dataset provenance, and signature checks on the servers themselves.

Ledger entries: gateway.tool_pinned, gateway.tool_drift

What the evidence supports

The Agent Environment Review flags agent setups that allow shell execution. A gateway policy can deny or hold MCP tools that run code, and records each decision.

What it does not establish

That code execution was prevented. An agent’s built-in shell tool is outside what the gateway decides. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry.

Not covered

Sandboxing, and analysis of generated code before it runs.

Ledger entries: policy.decision, gateway.tool_call

What the evidence supports

No direct evidence. DeepSweep does not look inside agent memory or retrieval stores.

What it does not establish

Anything about the integrity of an agent’s memory or context.

Not covered

Memory, retrieval and context stores.

What the evidence supports

No direct evidence. The ledger chains, and can sign, DeepSweep’s own records; it does not sign or check messages between agents.

What it does not establish

Anything about messages exchanged between agents.

Not covered

Agent-to-agent message authentication, integrity and confidentiality.

What the evidence supports

Policy decisions and outcomes for the calls the gateway decides are kept in a hash-chained record, signed entry by entry when the gateway runs with a signing key, that another party can check offline, which supports tracing what an agent did during an incident.

What it does not establish

That a failure did not spread. Timestamps are the recorder’s claim, an unsigned record shows only that it is internally consistent, and a signature identifies the recording install’s key, not each agent. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. Whoever holds the signing key can rewrite and re-sign the record and it still checks out; only a tree head received before the change, or one with an independent timestamp (checked separately; this kit does not check timestamps), catches that; a bundle received earlier catches it only if the change left fewer entries, because a bundle is compared by count.

Not covered

Tracing across multiple agents, and containing the spread of a failure.

Ledger entries: policy.decision, gateway.tool_call, gateway.tool_result

What the evidence supports

Each held call, each approve step and each redeemed approval token is its own entry, linked to the held call, so a reviewer can see which held calls were released and whether an approve step was recorded for each.

What it does not establish

That a person approved, or which one: the approver label is supplied, not authenticated. Nor that whoever approved understood what they approved, or was not misled into approving it. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry. The switch, tool pins and approvals are files in the workspace. The agent’s own user account can edit them. Only the gateway’s own changes are recorded, not edits to the files.

Not covered

How approval requests are explained to people, and guarding against over-reliance.

Ledger entries: gateway.tool_call, approval.granted, approval.consumed

What the evidence supports

A kill switch makes the gateway refuse the tool calls it decides, and drills record whether it worked. The ledger records the calls the gateway decided for the agent, signed entry by entry when the gateway runs with a signing key.

What it does not establish

That rogue behaviour was detected. Calls the gateway does not decide are neither stopped nor recorded. Calls refused by the kill switch, or because a tool’s definition changed, leave no entry. Turning the switch on or off with the command is recorded; deleting the switch file turns it off with no entry, and the agent’s own user account can delete it. Calls are recorded only while the ledger file reads cleanly; if it is damaged, the gateway still decides calls and forwards the ones it allows but writes no entry.

Not covered

Behavioural monitoring and agent identity attestation.

Ledger entries: gateway.killswitch, gateway.killswitch_drill, policy.decision