AI Agents Need Security Boundaries, Not Just Safety Guardrails

As AI agents gain the ability to act across enterprise systems, organisations must constrain capability; not rely solely on instructions about behaviour.

Artificial Intelligence is moving beyond answering questions.

AI agents can now browse websites, read documents, access repositories, call APIs, execute code and perform actions on behalf of users.

That changes the security conversation.

For traditional Generative AI, organisations often focused on safety guardrails.

What should the model be allowed to say?

Which prompts should it reject?

How should harmful requests be handled?

Those questions still matter.

But once an AI agent can take actions, safety guardrails are no longer enough.

The more important architectural question becomes:

What can the agent technically reach, access and execute if the guardrail fails?

That is the difference between safety and security.

Guardrails Influence Behaviour. Boundaries Limit Capability.

A safety guardrail attempts to influence what an AI system should do.

A security boundary determines what it can do.

The distinction is important.

An AI agent may be instructed:

“Do not access confidential information unless required.”

That is a behavioural expectation.

A security architect should ask a different question:

“Why does this agent have permission to access confidential information in the first place?”

If the agent does not require access, the permission should not exist.

The same principle applies to APIs, databases, cloud services, source-code repositories and administrative functions.

Good security architecture should never depend entirely on an intelligent system deciding to behave correctly.

Recent Incidents Make This Less Theoretical

In July 2026, Hugging Face disclosed an intrusion into part of its production infrastructure that it described as being driven end-to-end by an autonomous AI agent system. The campaign involved thousands of automated actions, credential harvesting and lateral movement across infrastructure. Hugging Face concluded that autonomous AI-driven offensive tooling was no longer merely theoretical.

The broader lesson is more important than the individual incident.

As AI agents gain more autonomy, organisations must assume that agents can behave unexpectedly, be manipulated or operate beyond what their designers originally intended.

An agent does not need malicious intent to create a security problem.

It only needs capability combined with the wrong objective, compromised context or excessive permission.

Treat Every AI Agent As An Identity

An AI agent accessing enterprise systems should not be treated as invisible automation.

It is effectively another identity.

It needs credentials.

Permissions.

Roles.

Access policies.

Audit trails.

Ownership.

And eventually, revocation.

This extends an argument I made previously in The New Security Perimeter Is No Longer The Network. It Is Identity.: modern trust increasingly depends on who or what is requesting an action and whether that identity should be allowed to perform it.

An AI agent with unrestricted access is therefore not simply an AI risk.

It is a privileged-access risk.

Least Privilege Must Apply To Agents Too

AI agents should receive only the capabilities required for a specific task.

An agent that summarises documents does not need administrative access.

An agent that creates service tickets does not necessarily need permission to close them.

An agent that reviews code does not automatically require production deployment rights.

An agent assisting with financial analysis should not automatically be capable of executing transactions.

OWASP’s current guidance for AI-agent security similarly emphasises least-privilege tool access, human approval for high-impact actions, sandboxing, monitoring and separation between decision-making and irreversible execution.

That is not unique to AI.

It is traditional security architecture applied to a new form of identity.

Separate Thinking From Doing

One architectural principle may become increasingly important:

Separate an agent’s ability to recommend an action from its ability to execute that action.

An AI agent may analyse a transaction.

Another control approves it.

An AI agent may recommend a configuration change.

A controlled workflow implements it.

An AI agent may identify a suspicious account.

A human or independent policy engine disables it.

The more consequential the action, the stronger that separation should become.

This is simply separation of duties applied to agentic systems.

We should not abandon decades of security principles simply because the actor is now Artificial Intelligence.

Assume The Agent Can Be Manipulated

AI agents increasingly consume information from untrusted environments.

Websites.

Emails.

Documents.

API responses.

Search results.

External datasets.

That information may contain instructions designed to manipulate the agent. OpenAI has described modern prompt-injection attacks as increasingly resembling social engineering against AI agents rather than simple prompt tricks.

Architecturally, this means external content should never automatically become trusted authority.

The agent may read something.

That does not mean the organisation should allow it to act on everything it reads.

There must be boundaries between:

Information → Decision → Authorisation → Execution

Collapsing those stages into one autonomous workflow increases risk significantly.

Human Oversight Still Matters

Human approval is sometimes dismissed as reducing the efficiency of AI automation.

For low-risk activities, that may be true.

But high-impact actions deserve friction.

Changing privileged access.

Deleting information.

Deploying production code.

Approving financial transactions.

Modifying security policies.

These are situations where a deliberate verification point may be valuable.

Convenience should not automatically override risk.

As I discussed in Convenience Is an Attack Surface, friction is sometimes an intentional security control rather than a design failure.

Final Thoughts

AI safety and AI security are related.

But they are not the same thing.

Safety guardrails attempt to influence behaviour.

Security boundaries constrain capability.

As AI agents become more autonomous, organisations need both.

Tell the agent what it should do.

But architecture must also determine what it cannot do.

Limit its identity.

Limit its permissions.

Limit its network reach.

Separate recommendations from execution.

Require independent approval for high-impact actions.

Monitor what it actually does.

Because eventually, a guardrail will fail.

A prompt will be misunderstood.

An agent will encounter malicious content.

An objective will produce an unexpected path.

When that happens, the organisation should not be relying on the AI to make the right decision.

The architecture should already have limited the wrong one.

AI agents need safety guardrails.

But security boundaries are what protect the business when those guardrails fail.

Question assumptions. Share knowledge. Build trust.