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?
Depending on its design, an agent may retrieve information, call APIs, update records, create tickets, send messages, modify workflows or trigger systems.
As organizations move from AI assistants to agents, security therefore has to evolve from controlling access to also controlling action.
Security built around human access
Identity and access management has long focused on users, service accounts and applications.
Identity controls authenticate users, assign permissions and monitor activity through least privilege, conditional and privileged access, network controls, logging and incident response.
Those controls remain essential.
Agents introduce identities that can use delegated authority, interact with multiple systems and make workflow decisions.
Microsoft’s AI-agent guidance recommends least privilege per tool or connector, authorization per action, human approval for high-impact actions and detailed auditing. Agent memory also requires protection against poisoning and inappropriate retention.
Granting agent access is only part 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?
Establish a control model before embedding agents across important business processes.
Establish agent identity and ownership
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?
Vendors are extending IAM to agents. Microsoft Entra Agent ID is designed to provide 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 data and action authority
Agents may need customer, operational or financial data without needing authority to modify the source systems.
For each agent, organizations should distinguish between what it can see and what it can do.
A customer-record assistant may need read access only. A purchasing agent may draft requests without approving transactions. A support agent may recommend changes that require human execution.
This is where AI security starts to become an architecture and governance decision, not simply another security product.
Limit tools and downstream actions
Agents become more powerful when they can call tools, APIs, connectors and other agents.
This creates value while increasing the impact of bad instructions, compromised credentials, manipulated context or unexpected model behaviour.
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.
Monitor agent actions
Traditional monitoring tells security teams when users log in, systems change or suspicious traffic appears.
Track agent requests, accessed resources, tools used and resulting actions.
Microsoft’s August updates address autonomous-action controls and agent visibility. Microsoft Digital describes validating agent scenarios with combined identity, endpoint, data-protection and security controls. NIST’s August Cyber AI Profile workshop report highlights AI attack surfaces and risk-based guidance.
Check existing capabilities before buying a dedicated AI security platform.
Check which controls your existing identity, Microsoft, SIEM/XDR, SSE/SASE, data-protection and application-security tools provide.
Technologies worth exploring
The right technology depends on what you are 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 address different needs. Most mid-market organizations will need a selection, based on their gaps.
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:
- Do we maintain an inventory of agents and their owners?
- Does each agent have a defined identity and least-privileged access?
- Have we separated data access from authority to take action?
- Are high-impact actions constrained or subject to human approval?
- Can we see which tools, APIs and resources an agent uses?
- Can we investigate an unexpected agent action after the fact?
- Have application-security and threat-modeling practices been extended to AI-specific risks?
- 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.
Scaling agents requires proven identity, data-protection and monitoring controls, extended for systems that act on your 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.