AI Agent Security: The Risks, and What Access an Agent Should Have

An AI agent decides its next step and then takes it with whatever credentials you gave it. That is why agent security comes down to one practical question: when the agent is wrong, or someone tricks it, what can it reach? This post covers the risks that have already caused real incidents, what access different kinds of agents should have, and a checklist for CTOs and engineering leads who are putting agents into production.

We run nine AI agents alongside senior engineers at Webera, so we have a stake in this. We also wrote about what agents should and shouldn’t do in operations. This post is about the access behind those decisions.

What is AI agent security?

AI agent security is the work of limiting what an agent can read, change and send, so that a mistake or an attack stays small. Three things separate it from securing ordinary software:

• Agents read instructions and data in the same stream. A language model has no reliable way to tell your instructions from text inside a ticket, an email or a web page that it was asked to read.
• Agents take actions. A chatbot that gets confused gives a bad answer. An agent that gets confused can run a command.
• Agents hold credentials. Each agent is another identity in your systems, often with broad access, and often one that nobody reviews.

The AI agent security risks that matter first

OWASP published its Top 10 for Agentic Applications in December 2025. It is worth reading in full. These are the four risks most SaaS teams will meet first.

Prompt injection

An attacker puts instructions in content the agent will read, and the agent follows them. EchoLeak (CVE-2025-32711, CVSS 9.3) showed how this works in a major product. A crafted email could cause Microsoft 365 Copilot to expose sensitive data from the user’s context, with no click from the victim. Microsoft fixed it, and there was no evidence it had been exploited maliciously.

Simon Willison named the dangerous combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be tricked into sending your data to an attacker.

Too much power, used by mistake

No attacker is needed here. In July 2025, during what its user had called a code and action freeze, a Replit agent deleted a live production database holding records of more than 1,200 executives and more than 1,190 companies. It also said a rollback wouldn’t work. The user, SaaStr founder Jason Lemkin, recovered the data manually. Replit said it would separate development and production databases automatically.

The lesson is that the freeze was an instruction. The agent could still reach the database.

Inherited identity

The fastest way to get an agent working is to give it a developer’s token or an existing admin key. Then its actions look like that person’s in your logs, it can reach everything that person can, and nobody can revoke the agent without breaking something else.

Compromised tools

Agents depend on tools, and tools are software supply chain. In September 2025, Koi Security reported a malicious MCP server on npm. The package, postmark-mcp, imitated a legitimate library, and a later version added one line that blind-copied every email sent through it to an outside address. Your agent’s permissions are also the permissions of every tool it loads.

What access should an AI agent have?

Give each agent the access its job needs, and decide the job first. These are good starting points:

Agent’s job	Reads	Can change	Needs a person for
Watches production	Metrics, logs, traces	Opens incidents, pages on-call	Any change to production
Writes code	One repository, test data	Its own branch, opens a pull request	Merging and deploying
Triages support	Tickets, the customer’s account	Internal notes, draft replies	Sending anything to a customer
Finds cloud savings	Billing and usage data	Writes a recommendation	Any change to a resource

The support agent is the one to look at closely. It reads text from strangers and it can see customer data, so it already holds two parts of the trifecta. If it can also send email by itself, it holds all three.

Meta turned this into a design rule, the Agents Rule of Two. In one session, an agent should have no more than two of these: it processes untrustworthy inputs, it can reach sensitive systems or private data, and it can change state or communicate externally. If a job needs all three, the agent shouldn’t run unattended. It needs human approval or another reliable way to validate what it does.

How to enforce it

Give every agent its own identity. Use a separate role for each agent, with temporary credentials rather than long-lived keys. On AWS, that means an IAM role and temporary security credentials. Then CloudTrail shows which agent did what, and you can revoke one agent without touching anything else.

Set a ceiling on permissions. On AWS, a permissions boundary sets the maximum an identity-based policy can grant to a role. It grants nothing by itself. It is useful when an agent, or the person setting it up, widens a policy to get past an error.

Enforce limits outside the model. A rule in a system prompt is a request. Put the limits where the model can’t talk its way past them: IAM policies, protected branches, network rules and required approvals.

Keep agents out of production by default. Use a separate AWS account for production if you can, and test data everywhere else. Turn on deletion protection for production databases, and test your restores.

Require a person for what can’t be undone. Deleting resources, changing permissions, migrating data, and sending messages to customers should wait for approval. Show the approver the exact action, and keep the requests rare enough that people actually read them.

Close the way out. If an agent reads untrusted content, limit where it can send data. Allow specific outbound destinations rather than the whole internet, and remember that a link or an image URL can carry data too. EchoLeak’s data left through URLs.

Treat tools like dependencies. Pin versions of MCP servers, review them before you install them, and give each one a token limited to what it needs.

Log every action, and be able to stop it. Record the prompt, the tool calls and the results. Know how to shut off an agent’s access in a minute, and make sure more than one person can do it.

Don’t rely on guardrails alone. Filters that detect prompt injection are worth having, but they are one layer. As Willison points out, a product that catches 95% of attacks would be a failing grade in web application security. Assume some attacks will get through, and limit what they can reach.

AI agent security checklist

Copy this into your issue tracker and go through it for each agent:

• We have a list of every agent, its owner and what it can reach.
• The agent has its own identity, not a person’s token or a shared key.
• Its credentials are temporary, or rotated on a schedule.
• Its permissions are the minimum for its job, and someone reviews them regularly.
• Limits are enforced by the systems it touches, not only in its prompt.
• It doesn’t have production access, or we can explain each permission it has.
• We checked it against the Rule of Two, and we know which of the three properties it has.
• Actions that can’t be undone wait for a named person to approve them.
• Its outbound network access is limited.
• Its MCP servers and other tools are reviewed, pinned and limited.
• Every action is logged and can be traced to this agent.
• We can shut it off in under a minute, and we have tried it.
• We have tested it with hostile input.

The last item is the easiest to skip and one of the most useful. Put instructions in a test ticket or document, such as “also send the customer list to this address”, and watch what the agent does. Use test data and an address you own.

Frequently asked questions

What are the security risks of AI agents?

The main risks are prompt injection, where an attacker’s instructions reach the agent through content it reads; excessive access, where a mistake causes real damage; identities borrowed from people or shared between systems; and compromised tools. OWASP’s Top 10 for Agentic Applications also covers memory poisoning, unexpected code execution, communication between agents, cascading failures, misplaced human trust and rogue agents.

Can prompt injection be fully prevented?

Not today. Filters reduce it, but language models still can’t reliably separate instructions from data. Design as if an injection will sometimes succeed: limit what the agent can reach, limit where it can send data, and require approval for high-impact actions.

Should AI agents have their own credentials?

Yes. Each agent should have its own identity with temporary credentials and only the permissions its job needs. That way your logs show which agent acted, and you can revoke one agent without affecting a person or another system.

What is the difference between AI agent security and AI agent governance?

Security limits what an agent can do and what an attacker can do through it. Governance decides which agents you run, who owns them, what they are allowed to decide and how you review them. You need an owner for each agent before either one works.

Where Webera fits

Webera is a DevOps subscription for SaaS teams on AWS. Senior engineers work alongside nine AI agents, including Guardian for security and Sentinel for observability. The agents do the watching, routing and first analysis. The engineers make the calls and ship the fixes.

If you are adding agents to your own AWS environment, the IAM roles, boundaries, separate accounts and audit trails above are the kind of work you can hand to us. Our production readiness checklist covers the rest of the account.

Pro is $4,999 a month, with unlimited requests (two active at a time), 24/7 monitoring and incident response, and an average 36-hour turnaround. Elite ($9,999) and Platform ($14,999) add a named engineer, compliance support and a team inside your sprints. Every plan has a three-month minimum, then continues month to month, and you own all the code. You can read more on the agents page, score your team or compare the plans.