Beyond Prompt Guardrails: Full‑Stack Security Governance for AI Agents

1. Least Agency vs. Least Privilege

While least privilege limits which accounts, APIs, databases, and files an agent can access, Least Agency goes further by asking whether the agent truly needs autonomous planning, continuous calls, cross‑system delegation, or long‑term memory. An agent that can only read orders but still initiates refunds, assigns work, and writes to shared memory poses a much larger risk than a simple permission issue.

Scope of control : Least Privilege – accounts, APIs, data tables, files, network ranges; Least Agency – autonomy depth, task‑chain length, delegation ability, memory scope, cross‑agent collaboration.

Typical problems : Unauthorized data access vs. unnecessary autonomous execution and propagation.

Governance actions : Permission tiering, short‑lived credentials, network isolation, resource‑scope constraints vs. splitting planning and execution, restricting auto‑delegation, mandatory approvals, shortening task chains, lowering default autonomy levels.

2. OWASP ASI01‑ASI10 Attack Surface

OWASP defines ten Agentic Application attack categories (ASI01‑ASI10). Mapping each to common Chinese enterprise scenarios helps teams quickly locate risks in their architecture.

ASI01 – Goal Hijack: malicious PDFs or emails cause a customer‑service bot to shift from “explain policy” to “seek exception compensation”.

ASI02 – Tool Misuse: a reimbursement agent that should only query orders also triggers payments, deletes records, and sends emails.

ASI03 – Identity & Privilege Abuse: shared bots inherit manager‑level OAuth scopes, automatically approving and bulk‑reading client data.

ASI04 – Supply‑Chain Vulnerabilities: third‑party MCP servers, knowledge plugins, or auto‑update scripts are replaced, poisoning all agents.

ASI05 – Unexpected Code Execution: a code‑generation agent runs unchecked shell commands, installs malicious packages, or corrupts production scripts.

ASI06 – Memory & Context Poisoning: forged refund rules written to long‑term memory are later reused by finance or quality‑control agents.

ASI07 – Insecure Inter‑Agent Communication: forged A2A registration nodes intercept and reroute sensitive orders.

ASI08 – Cascading Failures: a single erroneous quote contaminates approval, finance, shipping, and notification chains, leading to a system‑wide incident.

ASI09 – Human‑Agent Trust Exploitation: a financial copilot provides convincing payment instructions that persuade a manager to approve risky actions.

ASI10 – Rogue Agents: compromised ops agents continue to exfiltrate logs, fake health status, and replicate tasks.

The core insight is that prompt injection is only one entry point; the full risk chain spans input manipulation, tool‑driven actions, memory poisoning, and multi‑system propagation.

3. Four‑Layer Defense Architecture

Both OWASP and Microsoft’s Agent Governance Toolkit propose a pipeline‑style defense that stitches together input, runtime, output, and audit layers.

Layer 1 – Input Sanitization : Treat user messages, uploaded documents, RAG snippets, emails, web pages, MCP descriptors, Agent Cards, and A2A messages as untrusted. Perform prompt‑injection detection, document cleansing, source verification, tenant isolation, and namespace limits before the planner sees the data.

Layer 2 – Runtime Policy Execution : Decide whether automatic delegation, tool execution, credential usage, peer identity verification, or blast‑radius limits are allowed via an external policy engine. Microsoft’s toolkit implements runtime interception, identity trust, isolation, and a kill‑switch.

Layer 3 – Output Verification : Enforce verifiability for high‑risk tasks. Convert results to structured formats, then check groundedness, task adherence, business rules, and approval flow. Separate preview from execution; prevent raw explanations from becoming credential‑bearing actions.

Layer 4 – Audit & Forensics : Capture trace logs, task lineage, signed messages, hashes, policy hits, memory snapshots, and rollback points. Without this evidence, teams only know “something went wrong” but not why, how it spread, or whether it can be replayed.

Engineering focus for each layer:

Input – block prompt injection, document attacks, descriptor poisoning, cross‑tenant contamination.

Runtime – enforce Least Agency, JIT credentials, policy engine decisions, peer identity checks, and blast‑radius limits.

Output – validate groundedness, task adherence, structural constraints, and require human approval.

Audit – retain message lineage, policy hits, memory snapshots, replay evidence, and kill‑switch records.

4. Red‑Blue Adversarial Testing

Red‑team exercises validate that the defense pipeline can stop attacks across the full chain, not just a few jailbreak prompts. Microsoft and OWASP both stress continuous red‑teaming.

Red‑team actions vs. expected blue‑team observations (mapped to OWASP ASI numbers):

Inject hidden commands into PDFs, tickets, emails, or web summaries → Input sanitization should block (ASI01, ASI06).

Supply over‑broad tools or vague commands to trigger payments or deletions → Runtime policy should reject or require manual approval (ASI02, ASI03, ASI09).

Write forged policies or low‑trust rules into shared memory → Memory‑poisoning detection and namespace isolation should trigger alerts (ASI06, ASI08).

Forge A2A registration nodes, replay delegated messages, downgrade protocol versions → Identity verification and signature checks should fail (ASI07, ASI10).

Cause a single bad decision to fan out across multiple agents → Blast‑radius controls, rate limits, and kill‑switch should contain the cascade (ASI08, ASI10).

Key metrics to record: attack success rate, policy interception rate, error propagation radius, and recovery time. The blue team’s goal is to ensure every high‑risk attack ends in one of four controllable outcomes—blocked at input, rejected at runtime, stopped at output, or mitigated during audit.

5. Minimal Pre‑Production Security Checklist

Each high‑value agent must complete at least one exercise for document injection, tool misuse, memory poisoning, A2A masquerade, and cascading failure.

Every high‑risk action must be verified for policy denial, manual escalation, log persistence, and rollback capability.

Memory systems must scan writes, enforce namespace isolation, label sources, and provide snapshot/expiry mechanisms.

Multi‑agent systems must verify peer identity, message signatures, protocol versions, registration discovery, and kill‑switch functionality.

When input, identity, tools, memory, cross‑agent communication, human approval, and audit lineage are all linked, agent security becomes an operable infrastructure that assumes any layer can fail and uses the other layers to contain damage.