NEW: New Research: AI Agents and Algorithmic Redlining
Read Now
AGRC Framework / Domain 2
02
OWASP ASI02 (Tool Misuse), ASI08 (Excessive Autonomy), NIST AI RMF (Govern 1.2).
Domain Objective
The integration of the Model Context Protocol (MCP) and third-party plugins transforms agents from text-generators into kinetic operators. When an agent can execute code or manipulate APIs, the blast radius shifts from "Misinformation" to "Infrastructure Destruction." This domain enforces strict Semantic Gating and Isolated Execution, shifting the defensive perimeter from the prompt to the payload.
Controls
EX-2.1
Parameter-Level Allow-Listing (Deny-by-Default Execution)
The Rule — Control Statement
Access to MCP servers and external APIs shall operate on a strict Deny-by-Default posture. Access must be granted at the granular "Parameter" level, not the aggregate "Tool" level.
The Why — Fiduciary Rationale
Ensures that if an agent's intent is compromised (e.g., via prompt injection), the execution environment is physically devoid of the tools required to perform destructive actions.
The How — Implementation Standard
An agent shall not be granted blanket access (e.g., Allow: AWS). Access must be mathematically constrained to the specific function (e.g., Limit: EC2:DescribeInstances). Unconstrained terminal access (e.g., open Bash execution) is strictly prohibited.
The Proof — Continuous Attestation Evidence
Read-only export of API Gateway routing rules demonstrating rigid parameter-level constraints on all agent-accessible endpoints.
EX-2.2
Semantic Inspection Mandate (Beyond Schema Validation)
The Rule — Control Statement
API Gateways managing agent traffic must not rely solely on JSON schema validation. The architecture shall mandate Semantic Inspection via the Deterministic Governor prior to tool execution.
The Why — Fiduciary Rationale
A tool payload may be syntactically perfect JSON but semantically catastrophic (e.g., a properly formatted integer executing a hallucinated $50M wire transfer). The Governor must verify the intent of the payload, not just the format.
The How — Implementation Standard
The JSON payload must be vectorized and geometrically evaluated against the Governor's Policy Manifold before the tool is permitted to fire.
The Proof — Continuous Attestation Evidence
State-Tuple hashes proving the tool payload was mathematically evaluated, resulting in a PASS or RECTIFY signal, prior to transmission to the downstream tool.
EX-2.3
Read/Write Asymmetry and Idempotency Defaults
The Rule — Control Statement
The default operational state for all agentic database and API access shall be restricted to "Read-Only."
The Why — Fiduciary Rationale
Structurally prevents autonomous data corruption and ensures that "hallucinated" exploration does not result in state changes to the enterprise ledger.
The How — Implementation Standard
"Write," "Update," or "Delete" operations must be sequestered in a separate, highly privileged toolset requiring secondary cryptographic verification, strict idempotency checks, or deterministic semantic rectification (e.g., auto-appending LIMIT 100 to wide queries).
The Proof — Continuous Attestation Evidence
Database access control lists (ACLs) confirming Read-Only baseline roles mapped to standard NHIs, with explicit escalation logs for Write actions.
EX-2.4
Air-Gapped Ephemeral Sandboxing for Code Execution
The Rule — Control Statement
Any agent granted the capability to write, interpret, or execute code must operate within an ephemeral, containerized sandbox that is logically air-gapped from the corporate intranet.
The Why — Fiduciary Rationale
Neutralizes the "Just-In-Time" polymorphic malware threat identified in Google PROMPTFLUX by ensuring malicious code cannot achieve persistence or move laterally to adjacent corporate assets.
The How — Implementation Standard
The execution container must execute in ReadOnlyRootFilesystem: true mode to physically bar agents from rewriting files in their host directories.
The Proof — Continuous Attestation Evidence
Kubernetes/Docker security context configurations proving ephemeral, read-only root filesystems and explicit drop-all network egress policies.
EX-2.5
Zero-Trust Origin Authentication (SSRF Defense)
The Rule — Control Statement
All connections between the Agent and MCP Servers must enforce Strict Certificate Pinning and Mutual TLS (mTLS).
The Why — Fiduciary Rationale
Defends against the "Malicious Server" SSRF threat, ensuring the agent cannot be tricked into passing sensitive internal data to a hostile proxy server masquerading as a legitimate corporate MCP tool.
The How — Implementation Standard
Agents shall be mathematically barred from following unverified HTTP redirects or responding to unauthenticated DNS alterations.
The Proof — Continuous Attestation Evidence
Packet inspection and network logs proving mTLS handshake completion for 100% of agent-to-tool communications.
EX-2.6
Bidirectional Payload Sanitization (The "Boomerang" Defense)
The Rule — Control Statement
The outputs returned by external tools/APIs must be subjected to the same rigid sanitization as tool inputs before re-entering the agent's context window.
The Why — Fiduciary Rationale
Neutralizes the "Boomerang Attack," where compromised external APIs return massive payloads designed to destabilize historical context or embed Indirect Prompt Injections to hijack the agent's subsequent reasoning cycles.
The How — Implementation Standard
Tool outputs must be treated as untrusted, adversarial input. Return payloads must pass through length constraints, type-checking, and semantic sanitization via the Governor before being appended to the agent's memory stream.
The Proof — Continuous Attestation Evidence
System logs demonstrating the automated truncation or semantic blocking of anomalous payload returns from third-party tools.
EX-2.7
Orchestration-Level Algorithmic Circuit Breakers
The Rule — Control Statement
The orchestration layer shall implement strict, independent algorithmic circuit breakers and exponential backoff protocols for all tool executions.
The Why — Fiduciary Rationale
Prevents downstream Denial of Service (DoS) and automated account lockouts caused by an agent aggressively retrying failed operations (e.g., hammering an API with hallucinated passwords).
The How — Implementation Standard
Hard-caps (e.g., maximum 3 retries per tool) must be enforced at the infrastructure level, entirely decoupled from the LLM's internal reasoning loop.
The Proof — Continuous Attestation Evidence
Orchestration telemetry showing the deterministic severance of API connections upon reaching the defined retry threshold.
EX-2.8
Cryptographic State Verification (TOCTOU Defense)
The Rule — Control Statement
Execution tools must rely on cryptographic file hashes (not file paths) and strict database transaction isolation levels.
The Why — Fiduciary Rationale
Prevents Time-of-Check to Time-of-Use (TOCTOU) race conditions, ensuring that a file or asset approved by the Governor at Time A has not been maliciously altered by an external attacker at Time B (the moment of agent execution).
The How — Implementation Standard
Agents modifying files or database records must reference the asset's cryptographic hash rather than its mutable path name.
The Proof — Continuous Attestation Evidence
Execution logs capturing the cryptographic hash of the exact asset modified by the agent, mapped directly to the Governor's approval hash.
Ready to implement this domain?
See how Trinitite delivers continuous cryptographic attestation for Execution & Tooling controls out of the box.
Book a DemoTrinitite
The Guardian AI platform. Every decision — reviewed, corrected, protected.
Solutions
AGRC Framework
Research
Blog
© 2026 Fiscus Flows, Inc. · All rights reserved
The Guardian Standard™