AI security research hub
AI Agent and MCP Security
Research on AI agent identity, authorization, MCP security, tool access, agent skills, LLM risks, delegation, and audit controls.
Direct answer
What Is AI Agent and MCP Security?
AI agent and MCP security controls how agents receive identities, use delegated authority, call tools, handle untrusted context, and leave evidence of their actions. It combines application security, identity controls, protocol security, and model-specific defenses.
An agent can cross several trust boundaries during one task. A user request may lead to model planning, retrieval, an MCP tool call, an API request, and a change in an external system. Security decisions need to follow that chain instead of treating the model as a trusted operator.
How the Main AI Agent Security Layers Differ
These layers solve different problems. A deployment usually needs several of them at the same time.
| Layer | Question it answers | Typical controls |
|---|---|---|
| Agent identity | Which agent or workload is acting? | Workload identity, attestation, short-lived credentials |
| Authorization | What may it do for this user and task? | Resource scope, tool policy, approval, revocation |
| MCP security | Can the client trust the server, tool, and returned context? | Server allowlists, schema review, isolation, input validation |
| Model security | Can hostile content redirect or expose the system? | Prompt-injection defenses, data boundaries, output checks |
| Audit | Can the action and authority chain be reconstructed? | Actor, tool, arguments, decision, approval, result, token identity |
Start with identity and delegated authority
Authentication proves which user, client, workload, or agent is present. Authorization decides whether that principal may perform a specific operation on a specific resource. Agent systems need both decisions because a valid identity can still request an unsafe action.
Delegated access should get narrower as work moves through the system. Tokens should identify their intended audience, resource, scope, lifetime, and actor where the protocol supports it. A tool should enforce those limits at the resource boundary instead of relying on instructions inside a prompt.
Treat MCP servers and skills as software supply chain components
MCP servers and reusable agent skills can contain code, instructions, manifests, dependencies, and remote service calls. Review their source, version, permissions, update path, and runtime isolation before installation. A familiar tool name does not prove that its current implementation is safe.
Tool descriptions and returned content are untrusted inputs. Hosts should validate resolved operations and arguments with deterministic code, separate display text from policy, and require confirmation before destructive or externally visible actions.
Use OWASP lists as maps, not complete standards
OWASP publishes separate projects for LLM applications, agentic applications, MCP, and agent skills. Their scopes overlap, but the lists are not interchangeable. Record the edition or draft version used in an assessment because names and ordering can change.
A threat model should still identify the actual actors, data, tools, trust boundaries, and failure impact in the system. The OWASP articles below explain each list and connect its categories to architecture, authorization, testing, and monitoring work.