Check Point's Hamayun Recasts AI Agents as Privileged Non-Human Identities
Hamayun is Evangelist and Regional Security Architect at Check Point. His starting point is that agents no longer just answer questions. He describes agents that read email, access SaaS applications, query databases, invoke APIs, use Model Context Protocol (MCP) tools, modify records and run business workflows. In his words, AI is moving "from generating answers to taking actions."
He illustrates the risk with a hypothetical agent connected to Microsoft 365, Salesforce, ServiceNow, a cloud environment and internal databases. That agent could read information, make decisions, call tools and change systems, possibly within seconds and without a human approving each action. Hamayun stresses that the agent doesn't need malicious intent to be dangerous. His formula is that too much access, too much autonomy and too little oversight together create insider-like risk.
The comparison to privileged human accounts is deliberate. Organisations wrap administrators, privileged accounts and service identities in extra controls because those identities touch important systems and sensitive data. Hamayun's point is that a well-connected agent fits that description, so it deserves the same treatment. The interview offers no deployment statistics or incident data. It is a risk framing, and it should be read that way.
Least Agency Adds Action Control on Top of IAM and Least Privilege
Hamayun doesn't argue for replacing identity and access management. He calls IAM and least privilege essential but not enough on their own. Traditional IAM answers the question "what is this identity allowed to access?" Agentic AI, he says, forces a second question: should this agent perform this particular action, in this context, right now?
He describes that as the difference between access control and action or outcome control. Least privilege limits which resources an identity can touch. Least Agency, in his definition, means giving an agent only the autonomy it needs to accomplish its authorised business purpose, "and no more."
In practice he proposes three tiers. Some actions are allowed outright, some need extra context or human approval, and some are simply prohibited. This is proportional governance, not a demand that a human approve every step. The stated goal is to let security keep pace with AI adoption without slowing it down.
"Least Agency" is Hamayun's own label, not a formal control framework. The individual controls it implies are well established, though, and Microsoft has written them down in considerable detail.
Microsoft's Least-Privilege Pattern for AI Agents Supplies the Missing Mechanics
Microsoft published a Pattern & Practice on least privilege for AI agents in mid-July 2026, alongside a Microsoft Security Blog post by Yesenia Yser and Toby Kohlenberg. It reaches the same conclusion from the implementation side. The pattern says the security question shifts from whether an agent can complete a task to whether it should be allowed to perform each action, against which resources, and under whose authority. That is essentially Hamayun's access-versus-action distinction in Microsoft's words.
Microsoft's guidance explains why agents strain conventional permission models. Agents plan, chain actions across systems and call tools in sequence, often with no human approving each step. The blog describes how permission creep typically happens. A team gives an agent a broad Reader role because the first use case looks read-only. The workflow then grows to include fixing what the agent finds, and instead of redesigning the role, someone grants something broader and moves on.
The second risk Microsoft names is aggregation. An agent with access to email, files, a ticketing system and a code repository can look low-risk at each integration. The combination, however, lets it correlate data and take actions no one ever authorised as a whole. This is the mechanism behind Hamayun's "privileged insider" warning: individually reasonable permissions add up to a much broader effective capability.
Microsoft's pattern lists five challenges that give the Least Agency idea concrete edges:
- Identity ambiguity arises when agents run under shared secrets, service principals or mixed "on behalf of user" modes, so it's unclear who is responsible for an action.
- Permission creep and excessive aggregate privilege build up when broad pilot roles are never narrowed or many narrow roles combine into wide effective access.
- Over-broad tool access means a single prompt injection or workflow bug can trigger exports, deletions or privilege changes.
- Weak audit trails capture the chat response but miss the underlying tool calls, scopes and authorization decisions.
- Slow revocation happens when tokens persist, keys are shared or downstream systems don't re-check authorization.
The pattern also warns that prompts are not a security boundary. Relying on assurances that "the agent will only do X" instead of hard authorization limits invites prompt injection and workflow drift. That is the strongest technical case for Hamayun's approach. An agent's autonomy has to be restricted by enforced policy, not by instructions the model is expected to follow.
Named Owners Keep an AI Agent From Becoming an Orphaned Privileged Account
On accountability, Hamayun's answer is short: a human. Every production agent should have a clearly identified owner. Higher-risk agents should have two. The business owner answers why the agent exists and what authority it should have. The technical owner answers how it is configured, connected, authenticated, monitored and secured. His summary line is that agents can act autonomously, but accountability cannot be autonomous.
He warns that an agent with no identifiable owner should eventually be treated like an orphaned privileged account. Most identity teams already know that category: accounts whose owners have left, which nobody reviews and which attackers value.
Microsoft's guidance makes the same demand in operational terms. It calls for a unique, dedicated agent identity with a named owner and an explicit purpose, not a shared secret or a reused service account. It keeps the identity stable for lifecycle management while making elevated privileges temporary. Just-in-time (JIT) role activation, short-lived tokens or per-action approvals grant higher privilege only for the length of a specific workflow. Microsoft adds a warning that applies directly to agent pilots: temporary access with no expiry becomes permanent access in practice.
Entra already has plumbing for ownership changes. In a Microsoft Mechanics walkthrough of Entra Agent ID, Microsoft showed a lifecycle workflow in which an email is sent to the manager to notify them about an agent identity sponsorship change they will need to action. In the demo, when an agent's sponsor leaves their role, the manager needs to identify a sponsor for the two HR agents listed. That is Hamayun's orphaned-account concern handled as an automated joiner-mover-leaver process.
Entra Agent ID and Privileged Identity Management Turn Least Agency Into Configuration
For Microsoft shops, the tooling side is largely in place. Microsoft says Microsoft Entra Agent ID provides the identity platform capabilities for Microsoft Agent 365, enabling organizations to securely manage AI agents throughout their lifecycle. Microsoft's product page states that Agent ID capabilities are now available in Microsoft Agent 365 and Microsoft 365 E7 plans. That is a licensing boundary administrators should check before planning around it. According to one independent technical write-up, Agent 365 reached general availability on May 1, 2026.
Entra also enforces a platform-level limit on agent privilege. Microsoft's authorization documentation says Microsoft Entra blocks agents from being granted many high privilege roles or permissions. Users and administrators aren't allowed to consent to those powerful permissions for an agent. Microsoft's reasoning echoes Hamayun's: many high-privilege capabilities in Microsoft Entra ID assume a human administrator with careful intent, and an unrestrained agent with high privileges could perform unexpected administrative tasks with far reaching impact.
Microsoft's Agent ID best-practice guidance adds registration and scoping rules. It tells organisations to register every agent, whether built in Copilot Studio, Azure, or external platforms, in Microsoft Entra through the Agent ID framework. It also advises: don't grant broad permissions as a convenience. Limit permissions to specific scopes, API resources, or sites. Review and right-size permissions periodically.
The model extends to Power Platform. Microsoft's Dataverse guidance explains that an administrator creates a Dataverse agent user associated with the agent's Entra identity, which becomes the security principal inside that environment, where it can be assigned dedicated, least-privileged Dataverse security roles.
One limitation affects how far "context-aware" control can go today. An independent analysis by Engineer Up notes that Conditional Access and Entra ID Protection now extend to agent identities, but the grant control for non-human identities is limited to blocking access. Hamayun's middle tier, actions that need extra context or human approval, therefore can't be built with Conditional Access alone. For that tier, Microsoft points to other mechanisms. Its pattern says to introduce tool and action allowlists, and consider approval-based or time-bound elevation by using Microsoft Entra Privileged Identity Management for privileged operations.
Mapping the three Least Agency tiers to documented controls
The table below maps Hamayun's three outcomes to controls in Microsoft's published pattern. It is WindowsForum's editorial synthesis, not a Microsoft or Check Point mapping.
| Least Agency outcome | Documented control that implements it | Microsoft example scenario |
|---|---|---|
| Allowed | Task-based role scoped by resource, data label and operation, plus a tool allowlist | A read-only role for a document-summary agent, restricted to approved repositories and sites |
| Requires context or approval | JIT elevation, PIM activation, step-up approval, human approval for bulk actions | Human approval for bulk ticket updates; approval gates for running remediation runbooks |
| Prohibited | Actions left off the allowlist; subscription-wide rights denied; unreviewed tools and cross-tenant paths denied by default | A ticketing agent blocked from delete and admin actions |
Microsoft's pattern adds one requirement that is easy to miss. Downstream services must re-check claims, roles and scope on every call rather than trust the agent orchestrator. Otherwise, the weakest integration becomes the real boundary. The guidance also says audit logs should record the agent identity, role, effective scope, resource, action, timestamp, "on behalf of" user where relevant, and correlation IDs that link orchestrator, tool call and downstream system. Logging only the model's final answer produces an audit trail that looks complete but is useless for forensics.
What this means for you
If your organisation is running agents in production today, it should inventory them and assign owners before it approves any new agent projects. Teams still piloting can use the same checklist as their gate to production. Microsoft's blog gives a 30–90 day agenda: inventory agent identities, remove broad roles, introduce task-scoped RBAC, and require safe tool binding and end-to-end audit logs with monitoring before expanding deployments. It flags cross-tenant, guest and B2C agents as the highest priority.
Microsoft is also open about the costs. Its pattern lists more upfront design work, ongoing effort for JIT entitlements and access reviews, friction on high-impact operations, and a dependence on downstream systems enforcing authorization correctly. Those are the real trade-offs of Least Agency. Leaving an agent with a broad pilot role costs nothing up front, which is exactly why it tends to become the permanent setup.
- Give every production agent its own identity in Microsoft Entra Agent ID, with a named sponsor. Retire any shared secrets or reused service accounts.
- Assign higher-risk agents both a business owner who justifies their authority and a technical owner who is accountable for configuration, authentication and monitoring.
- Replace broad Reader, Owner or Admin roles left over from pilots with task-based roles scoped by resource, data sensitivity label and operation. Keep read and write roles separate.
- Put deletion, export, privilege changes and bulk updates behind allowlists, PIM-based elevation or human approval. Don't rely on prompt instructions to restrict them.
- Check that agent audit logs record identity, role, scope, action and correlation IDs across the whole tool chain, and verify your licensing (Agent 365 or Microsoft 365 E7) covers the Agent ID features you plan to use.
- Rehearse disabling an agent, rotating its credentials and invalidating its tokens, and re-review access whenever its tools, data scope or workflow change materially.
Hamayun's "Least Agency" label is new, but the idea underneath is not: autonomy is a privilege, and privileges need owners, limits and expiry dates. Microsoft's Entra Agent ID stack and its least-privilege pattern show that most of those controls already exist for Windows and Microsoft 365 environments. The exception is fine-grained, context-aware approval, which still needs PIM, allowlists and downstream enforcement rather than Conditional Access. Organisations that register, scope and assign owners to their agents now will be able to expand automation with confidence. Those that don't will end up with a growing set of powerful, unowned identities, the orphaned privileged accounts Hamayun warns about.