AI agents are moving rapidly towards production environments. Not because organisations have suddenly decided to grant artificial intelligence unrestricted access to critical systems, but because modern agent platforms are becoming operational actors rather than conversational assistants.

Today's agents can query databases, execute code, call APIs, invoke business functions, coordinate with other agents, and take action through an expanding ecosystem of tools. That changes the security conversation.

The question is no longer: Can the AI access production?

The question is: What authority does the AI have once it gets there?

That distinction matters. Access tells us whether the agent can reach a system. The authority determines what it is allowed to do once it gets there.

Platforms such as Snowflake and NVIDIA are accelerating the transition from conversational AI to operational AI. Agents can retrieve context, analyse information, invoke tools, execute workflows, and interact with business systems. As a result, AI is moving from answering questions to taking actions, shifting the security challenge from access management to authority management.

These capabilities create value. They also create new trust boundaries. The risk is no longer that a model produces an incorrect answer. The risk is that an incorrect answer becomes a legitimate action.

Traditionally, production access was straightforward:

User → Application → Production

Applications executed for predefined logic. If an engineer selected "Restart Service", the application performed a specific action determined by the developer.

Agentic systems are different:

User → Agent → Tool → Production

An agent asked to "investigate yesterday's outage and restore service if appropriate" may analyse logs, identify a failed deployment, decide a rollback is needed and execute it through an operational tool.

The user requested an investigation. The agent chose the action. That changes the security challenge. Access alone tells us very little about the level of control an agent has. What matters is not whether the agent has access, but which action it is authorised to choose and execute?

An agent may need permission to read logs and analyse telemetry. That does not automatically mean it should be able to restart services, modify configurations, or roll back deployments.

If an attacker influences the agent through prompt injection, poisoned data, or unexpected inputs, the resulting action may still be executed using legitimate credentials and approved tools. Nothing appears compromised, yet the outcome could still be a production incident.

Every tool expands an agent's authority. Every expansion of authority increases potential blast radius.

The more useful question is:

What actions can the agent perform, under what conditions, and what controls prevent a bad decision from becoming a production incident?

Consider a prompt injection attack.

If an AI system only generates text, the impact may be limited to producing an incorrect response. However, when that same system can invoke tools and perform actions, the risk changes significantly.

The attack path can become:

Malicious content → Trusted agent → Approved tool → Valid credentials → Production impact

For example, an attacker could hide instructions in a ticket, document, or knowledge article that an agent processes. The agent may interpret those instructions as part of its task, select an approved tool, and execute an action using legitimate credentials.

Several familiar security controls may still be functioning exactly as designed provided:

Yet the resulting action may still be something the organisation never intended.

The issue is not that the agent bypassed security controls. The issue is that it was allowed to make a poor decision within the authority it had been granted.

This is why authentication alone is insufficient for agentic systems. Authentication tells us who or what is acting, but not whether the action should be permitted in the current context.

In other words, an authenticated agent should not automatically be trusted to perform every action available to it. Just as Zero Trust avoids granting implicit trust based on identity or network location, agentic architecture should be designed so that each requested action is evaluated in context before it reaches production.

Treating production access as a simple yes or no permission hides an important distinction: different forms of access grant different levels of authority.

This describes operational authority rather than overall risk; read access to sensitive data may still represent significant confidentiality or privacy risk.

All five involve production access. However, only ‘autonomous production changes’ grant the agent broad operational authority, allowing it to independently choose and execute actions in production. The others primarily involve observation, analysis, recommendation, or tightly constrained operations.

Treating these very different capabilities as simply "production access" obscures the real risk.

Least privilege still matters, but agentic systems force us to rethink what it actually means.

With traditional applications, permissions were often easier to model because the application had a defined purpose, predictable actions, and a fixed permission model.

Agents are different. They can choose which tools to use, which systems to interact with, and which actions to take in pursuit of an objective.

That means we are no longer just managing access. We are managing authority. When designing an agent, organisations need to think beyond permissions and ask:

The goal is not simply to restrict what an agent can access. The goal is to control the impact of its decisions. Because in agentic systems, the real security question is not "Can the agent reach production?", It is "What happens if the agent gets the decision wrong?".

One of the most important principles in agent security is the separation of user authority from agent authority. An administrator may hold broad privileges because their role occasionally requires them, but an agent acting on their behalf should not automatically inherit the same level of access. For example, an engineer asking an agent to investigate a failed deployment does not require the agent to have unrestricted administrative rights across production systems. The authority granted to the agent should reflect the task being performed, not the maximum privileges of the person requesting it. Put simply:

User privilege ≠ Agent privilege

Agents should receive only the permissions necessary to complete the task and nothing more.

Most organisations are good at documenting what an agent should and should not do.

Far fewer are equally good at enforcing those rules when the agent actually attempts to perform an action.

That difference matters.

It is one thing to state that an agent must not modify production databases. It is another way to ensure that, even if the agent tries, the action cannot be executed.

If an agent’s existing credentials are enough to execute destructive commands without additional independent checks, then the restriction is not being independently enforced. That is not a security boundary. It is a hope-based control.

A stronger approach places independent controls between the agent and the systems it can affect:

Agent → Tool Request → Policy Decision → Privilege Check → Approval → Production

In practice, this means the agent does not get the final say.

The agent can propose an action. The security architecture decides whether that action is permitted.

For example, an incident-response agent might determine that restarting a service is the best course of action. Before that request reaches production, policy checks can verify whether the agent is authorised to perform the restart, whether the target system is in scope, whether additional approvals are required, and whether the request falls within predefined operational limits.

If any of those checks fail, the action is blocked regardless of what the agent intended to do.

That is the key principle: the agent should never be responsible for enforcing its own restrictions.

The agent's job is to make recommendations and act where authorised. The security architecture's job is to define the boundaries of that authority. Blurring those responsibilities is where risk begins.

Let's be realistic. No AI system is going to make the right decision every time. Neither do humans. Neither does automation. At some point, an agent will misunderstand an instruction, encounter malicious content, receive unexpected input, or simply choose the wrong action.

The interesting question is not whether that will happen. It is what happens next. If the agent gets something wrong, can it modify a single record or a million? Can it restart one service or take down an entire platform? Can it access one application or move across multiple systems?

Traditional security tends to focus on whether an action is allowed. With agents, we also need to think about the consequences if that action turns out to be the wrong one. In other words:

‘What is the maximum damage this agent could cause with the authority we have given it?’

That is what the blast radius is really about. Good security architecture assumes mistakes will happen, and designs controls around limiting the impact when they do.

As agents become more capable, that mindset becomes increasingly important. The goal is not to build an agent that never makes a bad decision. The goal is to stop a bad decision from becoming a major incident.

So, should AI agents have access to production? Sometimes, absolutely. Many of the most valuable use cases depend on it. Incident investigations, operational analysis, automated remediation, and workflow orchestration all become significantly more powerful when agents can interact with live environments.

But there is an important distinction between: Access to production and Authority over production. Those are not the same thing. An agent may need to access production data to do its job. That does not automatically mean it should have broad authority to change production systems. That is why production access should be: Task-specific. Constrained. Observable. Reversible. Revocable.

Start with the minimum authority the agent needs. Separate human permissions from agent permissions. Expose only the tools required for the task. Enforce policies at runtime, not just on paper. Require approval when the potential impact warrants it. And always know which agent did what, on whose behalf, and why. Most importantly, do not rely on the agent to enforce its own security boundaries. Because the real question is no longer: Can we trust the model? Models will make mistakes. Humans make mistakes. Software makes mistakes.

The better question is: When the agent gets it wrong, what prevents that mistake from becoming a production incident? That is the security boundary that matters. Not access. Authority.

I’d be genuinely interested to hear how you are approaching agent permissions, delegated authority, runtime controls, and production access in your organisations environments.

If you would like to discuss the topic further, challenge the viewpoint, or share your own experiences, feel free to contact me on LinkedIn or reach out directly. The industry is still defining what good agent governance looks like, and it is a conversation worth having.

Email: [email protected]