We spend a lot of time securing employee identities. We manage accounts, permissions, MFA, administrative access, and what happens when someone changes roles or leaves the company.
Now there’s another type of identity entering the business: AI agents.
As AI agents gain access to Microsoft 365, CRM systems, customer records, email, databases, cloud platforms, and business applications, they need credentials and permissions to do their jobs. That creates an important cybersecurity question:
If an AI agent can act inside your business, are you securing it like an identity?
An AI Agent Isn’t Just Another Application
Traditional generative AI was relatively easy to understand from a security perspective. You asked it a question, it generated a response, and a person decided what happened next.
Agentic AI changes that relationship. Depending on how it’s configured, an agent may be able to retrieve information, interact with applications, call APIs, execute workflows, send communications, update records, or perform other actions.
NIST has identified this as an emerging identity-management challenge, noting that AI agents may require access to multiple datasets, tools, and applications and therefore need appropriate identification and authorization controls.
Microsoft is approaching the problem similarly. Its Microsoft Entra Agent ID framework treats AI agents as identities that organizations can discover, manage, secure, and govern.
That’s an important shift. We’re no longer securing only people and devices. We’re securing digital actors that can take actions inside the business.
Every AI Agent Needs an Identity and an Owner
One of the biggest risks is allowing AI automation to disappear behind generic credentials, API keys, or service accounts.
Imagine an AI integration created six months ago. It has an API key, access to several applications, and permission to retrieve company information. The employee who created it has changed roles.
- Who owns it now?
- What can it access?
- When was that access last reviewed?
We explored a similar problem in our post, The Hidden Risk in the AI Gold Rush. Machine credentials and other non-human identities can quietly remain active long after anyone remembers why they were created.
Least Privilege Applies to AI Too
Least privilege means giving an identity only the access it needs to do its job. NIST defines the principle similarly: restricting privileges to the minimum necessary to accomplish assigned tasks.
We understand this with employees. Someone in marketing probably doesn’t need domain administrator access, and an intern probably shouldn’t have access to payroll, obviously.
AI shouldn’t be treated differently.
If an agent needs to read appointments from a calendar, does it need permission to delete them? If it retrieves customer information from a CRM, should it be able to export the entire database?
And if an AI agent drafts an email, should it automatically be able to send it?
Microsoft’s guidance on least privilege for AI agents makes an important distinction. The question isn’t simply whether an agent can perform an action. Organizations need to decide which resources and actions to authorize.
Instead of asking…
“What access does the AI need to work?”
Ask:
“What is the minimum access this AI needs to perform this specific job?”
Some Actions Should Still Require a Human
Permissions aren’t only about what information an AI agent can see. They’re also about what it can do with that information.
There is a big difference between allowing an agent to identify a duplicate customer record and allowing it to automatically delete one.
Higher-risk actions may warrant human approval, including:
- Deleting or modifying important data
- Changing user permissions
- Creating or disabling accounts
- Sending sensitive external communications
- Approving payments or financial transactions
- Changing cybersecurity settings
- Modifying production systems
- Executing actions involving regulated or confidential information
Microsoft has incorporated restrictions into Entra Agent ID around highly privileged permissions because an unconstrained agent with powerful administrative access could have significant consequences.
The principle applies beyond Microsoft: AI autonomy should match the potential consequence of the action.
That’s also central to Agentic AI Management Services. Some AI workflows can operate with considerable independence, while higher-risk activities may require human review, approval, or exception handling.
Human-in-the-loop isn’t necessarily an AI limitation. Sometimes it’s the security control.
Can You See What Your AI Agents Are Doing?
Imagine an employee accessing 10,000 customer records at 2:00 a.m. That would probably get someone’s attention.
What happens when an AI agent does it? Maybe that’s completely normal. Maybe it isn’t.
AI agents can perform legitimate actions at a speed and scale humans generally can’t, which makes monitoring especially important. Granting permission is only half the job.
Organizations should be able to answer questions such as:
- What resources did the agent access?
- What actions did it perform?
- Which identity or user authorized those actions?
- Was the behavior expected?
- Were unusually large amounts of data accessed?
- Were permissions or configurations changed?
- Can the activity be traced afterward?
NIST’s work on AI agent identity specifically highlights identification, authorization, auditing, and non-repudiation as areas organizations need to consider.
Logging and monitoring shouldn’t be something added after deployment. They should be part of the design.
This is also an extension of the identity-first approach we discussed in Identity Is the New Security Perimeter. Identity security becomes even more important when employees, applications, services, automated processes, and AI agents all have access to business systems.
Your Incident Response Plan Needs to Include AI
Suppose your security team discovers that an AI agent is behaving unexpectedly. Maybe its credentials were compromised, permissions were configured incorrectly, a third-party integration was breached, or the agent simply made a mistake.
What happens next? Your incident response process should address whether you can:
- Immediately disable the agent
- Revoke its credentials and tokens
- Determine which systems and data it accessed
- Identify actions it performed
- Prevent additional automated activity
- Roll back changes where possible
- Determine whether sensitive information was exposed
- Investigate the logs and establish what happened
NIST’s analysis of AI agent security found broad agreement that traditional cybersecurity practices remain relevant to AI agents but need to be adapted for agent-specific security concerns.
The important part is establishing those procedures before an incident occurs.
“Turn off the AI” isn’t an incident response plan.
AI Agents Need Onboarding and Offboarding Too
Organizations have processes for employees joining, changing roles, and leaving. AI agents need a lifecycle as well.
An agent may begin with one narrow purpose and gradually accumulate access. Someone connects it to Microsoft 365. Another employee adds the CRM. Six months later, it gains access to another application, while the original owner changes jobs.
Nobody revisits the permissions. That’s how access quietly accumulates.
Agent lifecycle management should cover:
- Initial provisioning and ownership
- Credential and secret management
- Permission approval
- Periodic access reviews
- Changes in business purpose
- Monitoring requirements
- Ownership changes
- Credential rotation
- Decommissioning
- Immediate removal of access when the agent is retired
Microsoft’s Entra Agent ID architecture reflects this emerging requirement by providing dedicated agent identities and, in some scenarios, agent user accounts for agents operating like digital workers.
When an agent stops working for your business, its identity should stop working too.
The Number of Non-Human Identities Is Going to Grow
This may ultimately be the bigger cybersecurity story.
AI agents don’t have to replace employees to dramatically increase the number of identities operating inside an organization. One employee might eventually work with several specialized agents, while sales, accounting, customer service, marketing, and IT each operate agents of their own.
Some may run continuously. Others may exist only for a particular workflow.
NIST launched its AI Agent Standards Initiative in 2026 partly because agents are increasingly interacting with external systems and internal business data while performing actions on behalf of users.
That means identity management can no longer focus exclusively on humans.
Seven Questions to Ask About Every AI Agent
You don’t need a 75-page AI policy to begin improving security. Start by asking seven questions about every significant AI agent operating in your environment:
- Identity: Does the agent have a clearly identifiable identity and owner?
- Access: What data, applications, and systems can it reach?
- Permissions: Does it have only the minimum permissions necessary?
- Actions: What can it do automatically, and what requires human approval?
- Monitoring: Can you see and audit what it’s doing?
- Response: Can you quickly disable it and revoke access if something goes wrong?
- Lifecycle: How are credentials, permissions, ownership, reviews, and retirement managed?
If you can’t answer those questions, your AI agents may have more freedom than your security strategy realizes.
That’s why Agentic AI Management Services should combine AI governance with identity and access management, cybersecurity, monitoring, Microsoft 365 integration, and managed IT.
It also connects directly with broader Cybersecurity Services, where identity, access, endpoint protection, monitoring, and layered security are treated as parts of the same security strategy.
AI Security Is Becoming Identity Security
AI agents will become more capable. That’s the point.
We want them to retrieve information, automate workflows, interact with applications, assist employees, and perform useful work. But greater capability requires greater access, and greater access creates greater risk.
That’s why securing agentic AI is not only about protecting the AI model. It’s increasingly about securing the agent’s identity and authority.
- Who is it?
- What can it access?
- What can it do?
- Who authorized it?
- What is it doing right now?
- How quickly can you stop it?
We’ve already explored what can happen when AI is given authority without adequate safeguards in What Happens When AI Deletes Your Database in 9 Seconds?. Permissions, logging, backups, human oversight, and governance become considerably more important once AI can take actions against real business systems.
The objective isn’t to make AI agents less useful. It’s to make sure their authority grows only as fast as your ability to control it.
Because once an AI agent can access your systems, use your data, and take actions on your behalf, it isn’t simply another AI tool.
It’s an identity. And identities need to be secured.
If your organization is deploying AI agents or connecting AI to Microsoft 365, business applications, customer data, or internal systems, Xecunet can help evaluate the identities, permissions, governance, and security controls surrounding them.