You Just Gave Your AI Agent the Keys to Production. You Probably Shouldn't Have.

Somewhere in the last six months, a threshold was quietly crossed.

AI agents stopped being things that generated text and started being things that did things. Real things. Things with consequences.

They are reading production databases. Pushing commits to main. Calling external APIs with real credentials. Sending emails on behalf of real people. Creating tickets, closing tickets, modifying configurations, triggering deployments.

The capability is genuinely exciting. The security model most teams are running it on is genuinely alarming.

And almost nobody is talking about it.

The access pattern that should not exist

When a team gives an AI agent access to their infrastructure, they almost always give it too much.

Not because they are careless. Because the path of least resistance in every agent framework, every integration tutorial, and every quickstart guide is to configure the agent with maximum access and figure out the restrictions later.

Later never comes.

The agent that was given read-write database access to make development easier still has read-write database access in production. The agent that was given admin API credentials to unblock a demo still has admin API credentials six months after the demo. The agent that can push to any branch because someone needed to test a workflow still can.

This is not a hypothetical. It is the current state of AI agent deployments at most companies that have moved beyond toy examples.

The access is excessive. The monitoring is minimal. The blast radius of a failure, a misuse, or a prompt injection attack is enormous.

The attack nobody has a playbook for

Prompt injection is not new. Security researchers have been writing about it since the first LLMs were connected to external data sources.

It has become dramatically more dangerous as agents have gained the ability to act on what they read.

The attack is straightforward. An agent is given a task that involves reading external content. A document. A webpage. An email. A database record. That content contains instructions disguised as content. The agent reads the instructions, interprets them as part of its task, and executes them.

A customer service agent reads a support ticket. The ticket contains text that looks like a system message instructing the agent to refund the maximum amount without verification. The agent does it.

A coding agent browses documentation for a library. A page in that documentation contains a hidden instruction to add a specific dependency to the project. The agent adds it. The dependency is malicious.

An agent processing invoices reads one that contains instructions to modify the payment destination for future invoices. The agent modifies the records.

These are not theoretical. Proof of concept demonstrations of each of these attacks exist publicly. The question is not whether they can be done. The question is whether your agent deployment is hardened against them.

For most teams, the answer is no.

Why the existing security model does not transfer

Every security principle used to protect traditional software applies to AI agents. The problem is that those principles were designed for systems where the instructions are code, and code does not change based on what it reads.

An API with read access to a database cannot suddenly modify that database because someone put unusual text in a record. The code is the code. It does what it was written to do.

An AI agent with read access to a database absolutely can be induced to modify that database based on what it reads. Because the agent’s behavior is determined by language, and language in the data can influence language in the prompt, and language in the prompt determines what the agent does.

The security boundary that traditional software takes for granted, the separation between instructions and data, does not exist for AI agents in the same way. Data can become instructions. Content can become commands.

This breaks the mental model that security teams have spent decades developing. The threat surface is not the code. It is every piece of text the agent reads.

Most teams have not updated their threat model to account for this.

The principle everyone forgot to apply

The security principle that would prevent most of these failures is not new. It has existed in software security for decades.

Principle of least privilege.

Every system, every user, every process should have exactly the access it needs to do its job and nothing more. Not the access that makes development convenient. Not the access that was provisioned during testing and never reduced. Exactly what is necessary for the specific task being performed.

Applied to AI agents, this means the agent that summarises documents should not have write access to anything. The agent that queries the database for reporting should not have the ability to modify records. The agent that drafts emails should not have the ability to send them without a confirmation step.

The access should match the task. Exactly.

This sounds obvious. Almost no deployed agent follows it.

Because following it requires doing work at build time that slows down development. It requires defining specific permission scopes. It requires building the infrastructure to grant and revoke those scopes per task rather than setting them once and forgetting them. It requires thinking, carefully and specifically, about what each agent actually needs.

That work is unglamorous. It does not make the demo better. It does not show up in the feature list. It is the kind of engineering that only becomes visible when its absence causes an incident.

The logging that does not exist

When a traditional application modifies a production database, there is a trace. Application logs. Database query logs. Audit tables. Some record of what happened, when, and in response to what.

When an AI agent modifies a production database, the trace is often inadequate or absent.

The action is logged. The reasoning that led to the action is not. The specific content that influenced the agent’s decision to take that action is not. The chain of intermediate steps that connected the original task to the eventual action is not.

This makes incident response for agent-related failures uniquely difficult. Something went wrong. The database was modified in a way it should not have been. But why? What did the agent read that led it to this decision? What sequence of reasoning produced this outcome?

Without the reasoning trace, you cannot answer these questions. Without the answers, you cannot fix the underlying issue. You can roll back the damage. You cannot prevent the same thing from happening again in a different form.

The teams that have figured this out are logging aggressively. Not just what the agent did. What it read, what it considered, what it decided, and why. Every step in the reasoning chain is a record that exists for audit purposes.

It is expensive to store. It is dramatically less expensive than being unable to explain a production incident to a customer, a regulator, or a board.

What a responsible agent deployment actually looks like

The teams running agents in production without incidents share a set of practices that the teams with incidents do not.

They scope access per task rather than per agent. The agent is not granted a fixed set of permissions. It is granted the minimum permissions for the specific task it is performing, for the duration of that task, and those permissions are revoked when the task completes.

They treat every external input as potentially adversarial. Documents, emails, database records, API responses, any text that the agent reads is treated with the same suspicion that a security team applies to user input in a web form. It is sanitised before it enters the reasoning context.

They put humans in the loop for irreversible actions. The agent can propose. Humans confirm. Anything that cannot be undone does not happen automatically regardless of how confident the agent is. The confirmation step is not optional and is not bypassable by the content the agent reads.

They log everything and review the logs. Not when something goes wrong. Regularly, proactively, looking for patterns that suggest the agent is being induced to behave in unexpected ways.

None of this is technically complex. All of it requires prioritising it before the incident rather than after.

The incident that changes the industry

There will be a specific, public, damaging incident involving an AI agent with excessive production access.

It might be a financial loss from a prompt injection attack on an agent managing transactions. It might be a data breach caused by an agent that was induced to exfiltrate records it had legitimate read access to. It might be an operational failure caused by an agent that modified infrastructure configurations in response to something it read in a log file.

When that incident happens, it will produce a wave of regulatory attention, security audits, and suddenly-urgent conversations about AI agent security that the industry is not having proactively.

The companies caught in that wave will spend months rebuilding trust with customers, explaining to regulators why their security model was inadequate, and retrofitting the controls they should have built from the start.

The companies that built those controls already will watch it happen from a comfortable distance.

The incident is coming.

The only variable is whether your company is in the first group or the second.

The access review you run this week is how you decide.