What does an AASB do that AppSec, IAM, EDR, CASB, and AI gateways do not?
Existing security categories were designed for systems that predate AI coding agents. AppSec scans static code. IAM and PAM govern who can log in. EDR watches process trees on endpoints. CASB inspects SaaS-app data flows. AI gateways proxy LLM API calls. None of them treat an AI coding agent and its MCP tool calls as the unit of analysis. An AASB does.
| Capability | AASB | AppSec | IAM / PAM | EDR | CASB | AI Gateway |
|---|---|---|---|---|---|---|
| Coverage scope: AI coding agents and their MCP tool calls | Partial | |||||
| Real-time enforcement on agent actions (block, approve, audit) | Partial | Partial | Partial | Partial | ||
| MCP server discovery, fingerprinting, and policy | ||||||
| Audit trail at agent-session and tool-call granularity | Partial | Partial | Partial | Partial | ||
| Deployment: workstation hooks plus optional gateway |
Categories overlap. An AASB does not replace AppSec or IAM. It adds the agent-action control plane that none of them cover natively.
Which AI coding agents does an AASB govern?
Any AI coding agent that reads files, executes commands, or calls tools through the Model Context Protocol (MCP). The Unbound AASB ships with first-class support for:
- Claude Code
- Cursor
- Windsurf
- GitHub Copilot
- Cline
- Roo Code
- Gemini CLI
- Codex
Any other tool that uses MCP is governed by default at the protocol layer. New agents inherit the same policy set without code changes on Unbound's side.
How is an AASB deployed?
Two complementary entry points, deployable independently:
- Workstation hooks via MDM. A lightweight script deployed through JAMF, Intune, or Kandji observes agent activity (file reads, terminal commands, MCP calls, LLM prompts) at the endpoint. Policies evaluate at the point of action and can audit, warn, block, or require human approval.
- Agent-account hooks. Direct integration with the agent's enterprise hooks API (Claude Code, Cursor, Codex) so policy applies the moment a developer signs in, before any workstation deployment completes.
Full org rollout takes days. Individual user activation takes minutes. Discovery in read-only mode runs first; enforcement is layered on once the security team is comfortable with the baseline.
Why does AI coding agent governance need a new control layer?
AI coding agents combine three properties that no existing security category was built to govern together:
- They run with full developer credentials: shell access, git permissions, cloud CLI tokens, database connections.
- They take autonomous multi-step actions on natural-language instructions, often with auto-approve enabled.
- They reach external systems through MCP servers that were typically configured by the developer with no security review.
That combination is the precondition for every documented MCP attack pattern: prompt injection via tool descriptions, tool poisoning, confused deputy, exfiltration, and chain-of-trust abuse. See the taxonomy of MCP attack patterns for the full reference.
An AASB closes the gap by governing what agents can do (write, exec, egress, privilege reuse) rather than trying to detect every attack vector that could produce those actions. Detection feeds policy. Policy is what bounds the consequences.
Further reading
- AI Coding Agent Security Glossary — every term used on this page, defined.
- What is an Agent Access Security Broker (AASB)? — long-form essay from the Unbound blog.
- Top MCP Server Risks in Production: A Red Team Walkthrough — three exploit chains end to end, mapped to AASB controls.