The first wave of enterprise generative AI raised an important security question: What data can the model see?
Agentic AI introduces a more consequential one: What is the AI authorized to do?
An AI agent can independently move a task through multiple systems, using available information to determine what happens next and carrying the process through to completion. It may do this across several systems without waiting for a person to approve each step.
“Assistive AI primarily helps people create, analyze, and decide. Agentic AI can go further by taking action,” says Ghazanfar Riaz Sheikh, Senior Vice President at Visionet Systems Inc. “Once an agent can use enterprise tools and execute transactions, it becomes part of the company’s control environment. We need to govern it as carefully as any other privileged identity.”
Visionet is seeing this shift across solutions developed with Microsoft Dynamics 365, Copilot, Power Platform, and Azure AI. Agents are moving beyond helping employees find information and are beginning to participate directly in the actual work.
Sheikh leads Digital Services and Microsoft-led transformation initiatives at Visionet. His work focuses on helping enterprises translate emerging technologies into practical business outcomes while establishing the architecture and governance needed to deploy them responsibly.
When AI moves from assistance to action
Agentic AI creates value by reducing manual work and accelerating decisions. The risk appears when an agent is manipulated, given excessive permissions, or asked to act with incomplete context.
A chatbot that produces an inaccurate answer creates an information-quality problem. An agent that acts on that answer can create a systemic problem.
For example, a customer-service agent might issue an unauthorized refund. A procurement agent could act on altered supplier information. A field-service agent might reschedule hundreds of appointments before anyone sees the pattern.
Malicious instructions could also hide in the messaging. An authenticated agent may then use legitimate permissions to perform something the user or organization never intended. Security professionals describe this as a “confused deputy” problem: the identity is valid, but the use of its authority is not.
“When agents invoke other agents, tracing accountability becomes more difficult,” Sheikh says. “One agent may retrieve the data, another may interpret it, and a third may complete the transaction. Security teams need visibility into the full sequence, not only the final system update.”
Every agent needs its own identity
Every enterprise agent should have its own governed identity, defined purpose, and accountable owner. It should not operate through shared service accounts or borrowed employee credentials.
A unique identity supports monitoring and allows access to be changed or revoked. Authentication, however, establishes only which agent is making the request. It does not determine whether the requested action is appropriate.
“In our enterprise discussions, we have found that organizations can usually identify their human administrators quickly, but often have less visibility into service identities, delegated permissions, and newly deployed agents,” Sheikh explains. “That gap needs to close before agents are allowed to execute critical transactions.”
Zero Trust has to extend beyond authentication
Zero Trust evaluates each request by taking into consideration whether the agent is authorized to perform the proposed action within the current business and risk context. Permissions should also be limited in duration and scope. An agent authorized to read an order should not automatically be permitted to change payment details. An agent that recommends a refund may still require separate authority to issue it.
This reflects Microsoft’s Zero Trust principles: verify explicitly, use least-privilege access, and assume breach. It also aligns with the resource-focused architecture in NIST SP 800-207.
Most enterprise security controls were designed around human users, assessing the circumstances of a sign-in to determine whether the person and device can be trusted.
Autonomous agents may operate through APIs and tokens without many of these signals. They can run continuously and act independently, on behalf of a user or through authority delegated by another agent.
Accountability has to follow the entire execution plan
Organizations need visibility beyond initial authentication. Significant actions should create a clear record showing how the agent was authorized, what it accessed, and how the request ultimately resulted in a transaction.
“The practical challenge is preserving accountability from the original request through to the business outcome,” Sheikh says. “If something goes wrong, the organization must be able to determine who initiated the work, what access was delegated, and which controls approved the action.”
An LLM-driven agent may respond differently depending on the context it receives and what has already occurred, meaning similar requests can follow different execution paths.
Sheikh recommends placing deterministic security controls around that probabilistic behavior.
“The model can recommend the next action, but it should not decide whether that action is authorized,” he says.
Putting boundaries around autonomous action
The amount of oversight should reflect the impact and reversibility of the action. Drafting a follow-up email presents a different level of risk from changing bank details. Higher-risk actions need human approval.
Each agent also needs a lifecycle. Its permissions should be reviewed as its role changes, and its identity should be retired when it is no longer required.
Runtime monitoring should provide visibility into how the agent operates, from the permissions it uses to the actions it ultimately completes. Abnormal behavior should allow the organization to suspend the agent, revoke its tokens, or stop an active workflow.
“An agent can complete several connected actions before a human analyst reviews a conventional alert,” Sheikh says. “Controls must be able to interrupt the activity while it is happening, particularly when money, sensitive information, or customer commitments are involved.”
The objective is for enterprises to define where that autonomy ends, which decisions require additional approval, and how to stop or reverse actions.
In practice, Zero Trust for AI agents depends on three things:
- A governed identity for each agent
- Clearly bounded authority for its actions
- An execution record that security teams can observe and interrupt.
Organizations that establish these controls early will be able to scale agentic AI with greater confidence and fewer surprises.
