AI Agent Security Checklist: Permissions, Approvals, MCP

This article gives you a practical security checklist for AI agents in a DevSecOps environment, focusing on locking down permissions, approvals, and Model Context Protocol (MCP) integrations. You’ll get concrete steps to reduce risk from overly broad access, unvetted tools, and prompt injection attacks.

Why AI Agents Are a New Security Boundary

Traditional DevSecOps secures code, containers, and cloud APIs. AI agents add a new layer: they can read files, call APIs, modify infrastructure, and take actions based on natural language instructions. This means the security model shifts from “who can run this command” to “what can this agent do, and under what conditions.” The core problem is that agents often require broad permissions to do their job, and those permissions can be abused—either by a malicious prompt, a compromised model, or a buggy tool call. The checklist below treats the agent as an untrusted remote user, not a trusted internal service.

The Checklist: Permissions, Approvals, and MCP

Use this as a starting point for your own audit. Each item maps to a specific risk.

1. Permissions: Principle of Least Privilege

• Scoped credentials: Give the agent its own service account or API key, not a human’s. Use cloud IAM roles (e.g., AWS IAM, Azure AD) that are narrowly scoped to the exact resources the agent needs. For example, if the agent only needs to read logs, don’t grant write access to S3.
• Time-bound access: Use short-lived tokens (e.g., AWS STS, OAuth 2.0 with short expiry) so a leaked credential is less useful.
• Network isolation: Run the agent in a separate VPC or namespace with egress controls. It should not have unrestricted internet access unless required.
• File system limits: If the agent reads local files, restrict it to a specific directory (e.g., /workspace) and use a read-only mount where possible.

2. Approvals: Human-in-the-Loop for High-Risk Actions

• Define risk levels: Classify actions as read-only (no approval), moderate (e.g., creating a pull request), or high-risk (e.g., deleting a production database, changing IAM policies).
• Mandatory approval for high-risk: For any action that modifies production infrastructure, requires a human to approve via a ticket system or a chat approval button. Do not let the agent auto-approve itself.
• Audit trail: Every approval must be logged with the requester, approver, timestamp, and the exact command or API call. This is essential for compliance and post-incident analysis.
• Break-glass procedure: Have a manual override that can immediately revoke the agent’s access if something goes wrong.

3. MCP: Securing Model Context Protocol Integrations

MCP (Model Context Protocol) is an open standard that lets AI agents connect to external tools (databases, APIs, file systems). It’s powerful, but it expands the attack surface.

• Vet every MCP server: Only install MCP servers from trusted sources. Check the code, the maintainer, and the permissions it requests. A malicious MCP server could steal data or execute arbitrary commands.
• Least privilege for MCP tools: Each MCP tool should have its own scoped credentials. Don’t give the agent a master database connection; give it a read-only user for the specific tables it needs.
• Input validation: The agent may pass user-controlled input to an MCP tool. Ensure the tool validates all inputs to prevent injection attacks (e.g., SQL injection, command injection).
• Network controls: MCP servers should be on a private network, not exposed to the public internet. Use mTLS or API keys for authentication.
• Rate limiting: Limit how many calls an agent can make to an MCP tool per minute to prevent abuse or runaway loops.

How to Implement the Checklist in Practice

Start by inventorying your current agent deployments. For each agent, list the tools it has access to, the credentials it uses, and the actions it can take. Then, apply the checklist iteratively:

1. Map the agent’s workflow: Identify every external call (API, file read, shell command) and every data source.
2. Create a permission matrix: For each action, decide if it’s allowed, and if so, under what conditions (e.g., requires approval, only in staging).
3. Implement with infrastructure as code: Define the agent’s IAM role, network policies, and MCP server configs in Terraform or CloudFormation so they are version-controlled and auditable.
4. Test with a red team: Try to prompt-inject the agent to see if it will perform unauthorized actions. Use a staging environment first.
5. Monitor and alert: Set up logging for all agent actions. Alert on unusual patterns, like an agent suddenly accessing a production database at 3 AM.

Common Mistakes and Misconceptions

• “The model is the security boundary.” It isn’t. The model can be tricked via prompt injection. The security must be enforced by the surrounding infrastructure—permissions, approvals, and sandboxing.
• “MCP is safe because it’s a standard.” The protocol is neutral; the risk is in the servers you connect. A standard doesn’t guarantee security.
• “We can just use a human’s API key.” This is a common shortcut, but it means the agent has all the human’s permissions, including ones it doesn’t need. It also makes auditing impossible.
• “Approvals are only for production.” Even in staging, an agent could cause significant damage if it has broad access. Apply the same controls everywhere, but adjust the approval threshold.

Costs and Trade-offs

Implementing these controls adds complexity and latency. Scoped credentials require more IAM management. Human approval adds friction to workflows. MCP server vetting takes time. But the cost of a breach—data exfiltration, infrastructure damage, compliance fines—is typically far higher. Start with the highest-risk actions and work down. You can also use automated policy checks (e.g., Open Policy Agent) to enforce permissions without manual review for low-risk actions.

Alternatives to MCP

If MCP seems too risky or complex, you have alternatives:

• Direct API calls: Write custom code that calls specific APIs with hardcoded, scoped credentials. This gives you full control but less flexibility.
• Function calling (native): Some LLM providers offer built-in function calling, which is similar to MCP but proprietary. It may have better integration with the provider’s security features.
• Sandboxed execution: Run the agent in a container or VM with no network access, and have it output commands that a human reviews and executes. This is the most restrictive but safest.

Frequently Asked Questions

What is prompt injection and how does it affect the checklist?

Prompt injection is when an attacker embeds malicious instructions in data that the agent reads (e.g., a web page or a document). The agent may follow those instructions, overriding its original task. The checklist mitigates this by limiting what the agent can do—even if it’s tricked, it can’t perform high-risk actions without approval.

Should I use a separate MCP server per tool or one that aggregates?

Separate servers are safer because you can isolate failures and permissions. An aggregate server becomes a single point of failure and may request broad permissions. Use separate servers unless you have a strong reason to combine them.

How do I audit what an AI agent actually did?

Log every action the agent takes, including the prompt, the tool call, and the result. Store these logs in a SIEM or a simple database. For MCP, enable server-side logging. For approvals, record the approval ticket ID. Regularly review logs for anomalies.

Can I use the same service account for multiple agents?

No. Each agent should have its own identity so you can attribute actions and revoke access individually. Shared accounts make auditing impossible and increase blast radius.

What if my agent needs to access a legacy system that doesn’t support modern IAM?

Wrap the legacy system in a thin API layer that you control. That API can enforce authentication, authorization, and rate limiting. The agent only talks to your wrapper, not the legacy system directly.

Is it safe to let an agent autonomously fix vulnerabilities?

Only in a sandboxed environment with no production access. Even then, the agent’s changes should be reviewed by a human before deployment. Autonomous fixes can introduce new bugs or be exploited. Always have a human in the loop for security-critical changes.

Related

• Recognize AI Images, Video and Audio: A Verification Guide
• GTA 6 Dual Protagonist Switching System Guide
• AI-Assisted Content Editing: Build a Better Workflow