AI agents change the security model: from access control to action control

For years, cybersecurity teams have built controls around a familiar question:

Who can access this system, application or data?

AI agents add another question:

What can this identity do once it has access?

That distinction matters because an AI agent can move beyond generating an answer. Depending on how it is designed, an agent may retrieve company information, call an API, update a record, create a ticket, send a message, modify a workflow or trigger another system.

As organizations move from AI assistants to agents, security therefore has to evolve from controlling access to also controlling action.

The traditional model was built around people and applications

Identity and access management has long focused on users, service accounts and applications.

Organizations authenticate an identity, assign permissions and monitor activity. Security teams use familiar controls such as least privilege, conditional access, privileged-access management, network controls, logging and incident response.

Those controls remain essential.

But agents introduce a new type of operating identity. They can potentially act with delegated authority, interact with multiple systems and make decisions across a workflow.

Microsoft's current AI-agent security guidance makes this shift concrete. It recommends least privilege for each tool or connector, authorization checks for each action, human approval for high-impact actions, and detailed action auditing. It also treats agent memory as a security boundary that can be exposed to poisoning or inappropriate retention.

That is a useful way for mid-market organizations to think about the problem: giving an agent access is no longer the end of the authorization decision.

AI-era security asks different questions

Traditional application security asks:

Is the application vulnerable?

AI-era application and agent security also asks:

• Can the model be manipulated?
• Can an agent be tricked into using a tool?
• Can its context or memory be poisoned?
• Can it retrieve information that the user should not see?
• Can it take an action outside its intended purpose?
• Can another agent or application influence its behavior?
• Can security teams reconstruct what happened afterward?

These are not reasons to stop using agents. They are reasons to establish a control model before agents become embedded across important business processes.

Start by giving every agent an owner and an identity

An agent should not become an anonymous automation that quietly accumulates access.

Organizations should be able to answer:

• Who owns or sponsors the agent?
• What business purpose does it serve?
• Which systems and data can it access?
• Which tools can it use?
• What actions can it perform?
• How long should that access exist?
• Who reviews it?
• How is the agent disabled when it is no longer required?

Identity vendors are beginning to extend familiar IAM concepts to agents. Microsoft Entra Agent ID, for example, is designed to give agents distinct enterprise identities, lifecycle governance, access policies and activity records.

The broader principle matters more than the product: agents should have attributable, governable identities rather than inherited or overly broad authority.

Separate information access from action authority

A useful agent may legitimately need to retrieve customer, operational or financial information. That does not mean it should automatically be able to modify the systems containing that information.

For each agent, organizations should distinguish between what it can see and what it can do.

An agent that summarizes customer records may need read access but no authority to change them. An agent that prepares a purchase request may be allowed to create a draft but not approve the transaction. A support agent may recommend a change but still require a human to execute it.

This is where AI security starts to become an architecture and governance decision, not simply another security product.

Put boundaries around tools and downstream actions

Agents become more powerful when they can call tools, APIs, connectors and other agents.

That creates business value, but it also increases the potential impact of a bad instruction, compromised credential, manipulated context or unexpected model behavior.

Teams should review:

• which tools are available to each agent;
• which API operations are permitted;
• whether high-impact actions require human approval;
• whether transactions have value or volume limits;
• whether the agent can create or modify other identities;
• whether access can be restricted by environment or network;
• how secrets and credentials are protected;
• whether actions are logged in enough detail to investigate later.

The goal is not to prevent autonomy. It is to bound autonomy to the business purpose.

Monitoring has to include what agents actually do

Traditional monitoring tells security teams when users log in, systems change or suspicious traffic appears.

Agentic environments need another layer of visibility: what the agent requested, which resource it reached, which tool it used and what action followed.

Microsoft's August security updates are already moving in this direction, with guidance around constraining autonomous agent actions and gaining visibility into agent activity. Microsoft Digital has also described its own enterprise work to validate secure agent scenarios using identity, endpoint, data-protection and security controls together. NIST's August Cyber AI Profile workshop report similarly highlights AI attack surfaces and the need for risk-based guidance as organizations secure AI-enabled systems.

This is a useful reminder for smaller organizations: the answer does not necessarily begin with buying a dedicated AI security platform.

Start by asking whether your existing identity, Microsoft, SIEM/XDR, SSE/SASE, data-protection and application-security tools can already provide part of the control environment.

Technologies worth exploring

The right technology depends on what you are actually deploying.

For a Microsoft-centric organization beginning with Copilot and low-code agents, technologies to evaluate may include:

• Microsoft Entra Agent ID / Agent 365 for agent identity, lifecycle and access;
• Microsoft Purview and Defender capabilities for information protection, visibility and security controls;
• the organization's existing Sentinel, Defender or other SIEM/XDR platform for monitoring and investigation.

Organizations developing custom agents or AI applications may also need to evaluate specialist capabilities such as:

• Cisco AI Defense;
• Zscaler AI Security;
• Netskope AI Security;
• Cloudflare AI Gateway / AI Security;
• Palo Alto Networks Prisma AIRS in higher-complexity environments;
• red-team, evaluation and secure software-supply-chain capabilities appropriate to the development environment.

These products solve different parts of the problem. They should not be treated as interchangeable, and most mid-market organizations will not need all of them.

The first question should remain:

What business process are we enabling, what authority does the agent require, and which controls can we extend from the technology we already own?

What leaders should do now

If your organization is beginning to pilot agents, add these questions to the project before expanding deployment:

1. Do we maintain an inventory of agents and their owners?
2. Does each agent have a defined identity and least-privileged access?
3. Have we separated data access from authority to take action?
4. Are high-impact actions constrained or subject to human approval?
5. Can we see which tools, APIs and resources an agent uses?
6. Can we investigate an unexpected agent action after the fact?
7. Have application-security and threat-modeling practices been extended to AI-specific risks?
8. Are our existing security platforms sufficient, or is there a real gap that justifies another technology?

AI agents do not make existing cybersecurity obsolete. They extend it.

The organizations that scale agents successfully will be the ones that carry forward proven identity, data-protection and monitoring principles while adding the controls required for systems that can increasingly act on their behalf.

Not sure which controls or technologies fit your environment? Speak with a Cybersafer advisor. We'll start with your business priorities, existing architecture and risk before recommending a path forward.