Agentic AI Security: When AI Starts Acting on Its Own

Why the next phase of AI adoption shifts the security conversation from controlling access to governing authority

Generative AI created a data-security challenge. Agentic AI creates an authority challenge.

‍

The conversation has moved on

Over the past year, a change has become visible in many enterprise conversations. The question is no longer whether organizations should use AI. Most have already crossed that bridge. The harder discussion is about how far AI should be allowed to go: which information it can reach, which systems it can use, what decisions it can influence and, eventually, what actions it can take.

That distinction matters because an assistant and an agent do not create the same risk. An assistant may find a policy, summarize a contract or draft a response. An agent can be asked to complete a task across several systems. It may retrieve a document, compare records, call a tool, update a workflow and send a message. As we've explored in From Copilots to Agents: Why the Next Phase of AI Demands Reinvention, Not Experimentation, the technology has moved from helping a person understand work to participating in the work itself.

Most security models were built around people, applications and workloads. Each has an identity, a set of permissions and a reasonably predictable operating pattern. An AI agent is different. It can act for a person, use several tools during one assignment and change its route as new information appears. That makes its authority harder to see and easier to overextend.

The risk is no longer limited to what AI knows. It includes what AI is allowed to do.

‍

Access is not the same as authority

Traditional security asks two familiar questions: Who are you? What are you allowed to access? Agentic AI introduces a third: What are you permitted to do once you get there?

A finance agent may need to read an invoice, but that does not mean it should be able to change a vendor record. A service agent may need customer history, but it should not automatically be allowed to issue an unlimited refund. A coding agent may prepare a release, but production deployment may still require a named person to approve it.

This sounds like a small extension of least privilege. In practice, it is a deeper design problem. Many early agents inherit broad user or application permissions because that is the fastest way to make a demonstration work. As we found when examining what breaks first when banks deploy AI agents, the result can be an agent with more reach than the task requires and fewer practical checks than a human employee would face.

The principle should be simple: an agent's authority should be no greater than the authority needed for the specific task, and consequential actions should carry explicit limits, verification and accountability.

‍

Why this is becoming a burning issue

Three forces are arriving at the same time. First, agents are being connected to business systems rather than isolated in experiments, a shift documented in our review of what most banks get wrong about agentic AI. Second, business teams can assemble useful automations with far less specialist effort. Third, untrusted content, such as an email, attachment, web page or retrieved document, can influence an agent that also has legitimate access to enterprise tools.

That combination changes the radius of a mistake. A manipulated answer is undesirable. A manipulated action may alter a record, disclose information or trigger a business process. The problem does not require a malicious model. It can arise when an otherwise useful agent is given broad permissions, trusts the wrong instruction or acts without an appropriate checkpoint.

‍

From shadow AI to shadow agents

Many companies have spent the last two years finding unsanctioned AI tools. The next visibility gap may be harder: small agents created inside teams, connected to mailboxes, document stores, CRM platforms, databases or workflow tools. Each one may look harmless in isolation. Together, they can create a new population of non-human actors whose owners, privileges and dependencies are not clearly recorded.

An approved list of models will not solve this. Enterprises will need an inventory of agents, the people accountable for them, the data they touch, the tools they invoke and the actions they can execute, the kind of discipline set out in our framework for operationalizing AI risk governance in financial services. The inventory must stay current because an agent's risk changes when a new connector, tool or permission is added.

‍

When one agent delegates to another

Multi-agent workflows make the authority question sharper. If one agent asks another to complete part of a task, which permissions travel with the request? Can the second agent delegate again? Where does the chain stop? These questions echo what we've seen in transaction monitoring's shift toward multi-agent AI: if the outcome is wrong, can the organization reconstruct which agent acted, which instruction it followed and whose authority was used?

These questions are no longer confined to research teams. NIST has begun examining identity and authorization for software and AI agents, including auditability and controls against manipulated instructions. Major identity platforms are also introducing agent-specific identity and governance capabilities. The direction is clear: agents are becoming first-class enterprise identities, not merely features inside applications.

The next security perimeter may be the boundary around what an AI agent is authorized to do.

‍

A practical security architecture for agentic AI

Enterprises do not need a separate security universe for AI. They do need to extend familiar disciplines, the same ones outlined in our conceptual framework for effective AI governance, into the places where agents create new risk. A useful starting point looks like this:

‍

What leaders should do now

The immediate task is not to stop agents. It is to make authority visible before autonomy spreads faster than governance. Five moves are practical now:

• Build an agent inventory that includes owners, systems, data, tools and delegated connections.

• Classify use cases by data sensitivity, business impact and level of autonomy, not by model sophistication alone.

• Separate read, recommend, prepare, approve and execute permissions. Do not treat them as one broad entitlement.

• Keep human approval where consequences are material, irreversible or difficult to detect after the fact.

• Monitor what agents actually do in production, and make the evidence usable by security, risk and business owners.

These moves are the practical counterpart to the regulatory expectations already emerging for automated decisions, similar in spirit to what we've outlined in AI for onboarding: what regulators expect in the age of automation.

‍

Security should enable more autonomy

It is tempting to frame these controls as friction. The opposite is closer to the truth. Companies will only entrust agents with meaningful work when leaders can understand their authority, limit their radius and explain their actions. Strong boundaries create the confidence to automate more.

That confidence is also what separates a working demo from what we define elsewhere as production-ready AI in financial services: a system an enterprise can trust with real decisions, not just a proof of concept.

The defining question in the next phase of enterprise AI will not be how intelligent our agents can become. It will be how much authority we are prepared to give them, and whether our security architecture is ready for that responsibility.