AI agent security covers the deployed system around the model: instructions, tools, files, credentials, network access, external components, permissions, and the actions the agent can take.
FOUNDATIONAL GUIDE
A Practical Guide to AI Agent Security
Map component, tool, runtime, data, and MCP risks to controls, verification steps, and explicit residual boundaries.
01AI agent security covers the deployed system around the model: instructions, tools, files, credentials, network access, external components, permissions, and the actions the agent can take.verify
02Start with the outcome your team cannot accept, then trace the assets, trust boundaries, actions, and evidence connected to it.verify
03Unacceptable outcomeverify
04Asset and permissionverify
LEARNING / 01
Define the AI Agent Attack Surface
LEARNING / 02
Build a Threat Model
Start with the outcome your team cannot accept, then trace the assets, trust boundaries, actions, and evidence connected to it.
IntroStart with the outcome your team cannot accept, then trace the assets, trust boundaries, actions, and evidence connected to it.
Worksheet ColumnsUnacceptable outcomeAsset and permissionEntry pathControl pointEvidence and residual gap
CriterionUnacceptable outcome: A coding agent sends a secret to an unapproved endpoint.Asset and permission: Repository credential available to the agent process.Entry path: Tool instruction followed by a network request.Control point: Component review, least privilege, and a runtime decision before the request.Evidence and residual gap: Decision record, destination, policy version, and any path outside the integration.
Prompt ListWhat can the agent change?Which components can influence it?Which actions cross a trust boundary?What evidence would prove the control worked?
LEARNING / 03
Review Components Before Trust
Treat every skill, plugin, package, agent, and MCP server as a component with a source, permissions, dependencies, configuration, update path, and expected behavior.
Treat every skill, plugin, package, agent, and MCP server as a component with a source, permissions, dependencies, configuration, update path, and expected behavior.
Publisher and source
Package or repository integrity
Requested permissions
Dependencies
Tool descriptions and instructions
Configuration and endpoints
Update history
Expected runtime behavior
Before first trust
After a version or configuration change
After permission changes
After unexpected behavior
AgentGuard publicly documents Deep Scan for skills, plugins, MCP servers, and agents, including named risk categories. A scan result does not prove universal safety.
Review Deep Scan
/features/deep-scan
LEARNING / 04
Evaluate High-Risk Runtime Actions
Prioritize actions that can change systems, expose data, or extend trust. Decide where a policy check must occur before execution.
Prioritize actions that can change systems, expose data, or extend trust. Decide where a policy check must occur before execution.
Shell commands | Is the command and target allowed in this context? | Command, target, decision, policy version | Commands outside the integration remain a residual path.
File access and sensitive writes | Is the path, operation, and content class allowed? | Path class, operation, decision | Host and permission coverage must be verified.
Tool actions | Is the tool trusted and is this invocation expected? | Tool identity, arguments, decision | Similar tool names do not establish equivalent behavior.
Network requests | Is the destination and payload class approved? | Destination, request class, decision | Unknown or indirect network paths require separate controls.
Secret access | Does the workflow require this credential? | Credential class, requester, decision | Do not place raw secrets in audit content.
AgentGuard publicly documents Runtime Guard for named action categories. Protection depth depends on the integration path.
Review Runtime Guard
/features/runtime-guard
LEARNING / 05
Plan for MCP Boundaries
Host → MCP server → tool description → permission → request → returned content → downstream action
Who operates the server?
Which tools are exposed?
What permissions and data can they reach?
How can returned content influence the agent?
Which calls are observable or blockable?
MCP server scanning, reputation and trust-related controls, and hook-layer protection are publicly described.
AgentGuard's public FAQ says it cannot fully monitor or block all third-party MCP server runtime calls.
Open MCP & Agent Security
/solutions/mcp-security
LEARNING / 06
Define Data and Evidence Boundaries
Document which code, prompts, files, secrets, action previews, metadata, and events remain local or may reach a connected service.
Decide which action, decision, policy version, component result, exception, and review trigger must be retained without recording raw sensitive content.
What leaves the environment?
What is redacted?
What is cached offline?
Who can inspect the evidence?
How long is it retained?
AgentGuard public materials distinguish local protection from cloud-connected use and describe redacted or sanitized metadata and audit events. Formal privacy commitments still require the authoritative policy.
Review AgentGuard Security
/security
LEARNING / 07
AI Agent Security Implementation Checklist
Name the workflow, owner, environment, and users in scope.
List instructions, components, tools, data, permissions, and external services.
Define unacceptable outcomes and the assets they affect.
Review components before trust and after material changes.
Apply least privilege to the agent, host, tools, and connected services.
Place runtime decisions before the highest-impact actions where the integration supports them.
Test expected allow and high-risk paths with known inputs.
Inspect the evidence produced and remove sensitive content from logs.
Record exceptions, unsupported paths, and residual MCP gaps.
Set the next review trigger for component, policy, integration, or environment changes.
Use the Security-Team Evaluation Path
/solutions/security-teams
LEARNING / 08
Make Residual Risk Explicit
No single scan, policy, or runtime control proves complete AI agent security. Record the paths the control cannot observe, the actions it cannot block, the evidence it does not retain, and the owner of the remaining decision.
Step 01
No single scan, policy, or runtime control proves complete AI agent security. Record the paths the control cannot observe, the actions it cannot block, the evidence it does not retain, and the owner of the remaining decision.
Next Step 1
Need implementation details?
Next Step 1
Open AgentGuard Docs
Next Step 1
/docs
Next Step 2
Need component review?
Next Step 2
Review Deep Scan
Next Step 2
/features/deep-scan
Next Step 3
Need runtime decisions?
Next Step 3
Review Runtime Guard
Next Step 3
/features/runtime-guard
LEARNING / 09
Frequently Asked Questions
What belongs in an AI agent attack surface?
Instructions, components, tools, files, credentials, networks, permissions, external services, executable actions, and the evidence produced by the workflow.
When should agent components be reviewed?
Before first trust, after material updates or configuration changes, after permission changes, and after unexpected behavior.
Which actions need runtime checks?
Prioritize actions that can change systems, expose data, access secrets, call external tools, write sensitive files, or reach unapproved networks.
Can a component scan prove an agent tool is safe?
No. A scan can provide evidence for named checks, but permissions, configuration, updates, runtime behavior, and unsupported paths still require review.
What residual MCP risk remains?
Third-party MCP runtime calls may remain outside complete monitoring or blocking coverage, depending on the host and integration path.
Continue from Concept to Practice
Use the relevant guide, product documentation, and current first-party evidence to verify the next step.