A recent InformationWeek report put that concern directly, relaying warnings from security leaders at Intuit, ETS/PSI, and Smartsheet about agent sprawl, identity, and governance. The scenario is a risk-management warning, not evidence of a disclosed orphaned-agent breach at any of those organizations. That distinction is essential. Even so, the underlying technical concern is well supported: agents granted access to data, tools, and applications require identification, authentication, authorization, oversight, and a defined end of life.
For Windows administrators and enterprise IT teams, this is not a separate AI-security project to postpone until agent deployments are larger. It is an extension of identity governance, privileged-access management, application inventory, change control, and employee offboarding—except that the entities being governed may operate at machine speed and reach across systems in ways their creators did not fully anticipate.
The real problem is unmanaged delegated authority
“AI orphan” is useful shorthand because it identifies a gap that conventional asset management can miss. A laptop has an assigned user, a serial number, and a retirement process. A server normally has an owner, patching responsibility, and a place in inventory. An agent may instead begin as a limited experiment, an automation feature, or an assistant connected to several business services. Its benefit can be immediate while its ownership and permission model remain informal.
The risk rises when the agent receives broad authority. An agent that can read documents, search customer records, create tickets, submit changes, send messages, or invoke external tools is not merely generating text. It is operating through identities and permissions. Those permissions may be inherited from a creator, granted through a shared non-human account, attached to a generic integration, or delegated through an authorization flow.
OWASP identifies excessive functionality, permissions, and autonomy as important causes of excessive agency. Its recommended direction is practical: grant only minimum necessary permissions; use the user’s authorization context where appropriate; require approval for high-impact actions; and ensure downstream systems continue to enforce their own policy.
That last point corrects a potentially costly assumption. Putting an AI interface in front of a business system does not remove the system’s responsibility to decide whether a requested action is allowed. An agent should not become a convenient route around the authorization checks that would apply if a person performed the same work directly.
Employee departure is a resilience test, not proof of an incident
The reported example of an employee leaving while their agents and associated accounts remain active makes the governance gap concrete. It should be read as a hypothetical lifecycle failure, not as a reported event at Intuit, Smartsheet, ETS, or PSI.
It nevertheless exposes the right operational questions. When an employee departs, organizations commonly disable the employee’s own account. Can they also identify every agent the person created or sponsored? Can they find every connector, credential, delegated permission, tool endpoint, workflow, or non-human identity related to that work? Is there another named owner with the authority to determine whether the agent should continue operating?
If the answer is no, disabling the former employee’s account may not resolve the full risk. But indiscriminately disabling every associated automation can disrupt legitimate business processes. Resilience depends on having enough visibility to make a deliberate decision: reassign the agent, narrow its scope, pause it pending review, or retire it and revoke its access.
Ownership is therefore more than a documentation field. It links an automated capability to a person or team able to explain its business purpose, review its authority, and turn it off.
Agent identity is foundational, but the implementation is still evolving
The National Cybersecurity Center of Excellence at NIST frames secure software and AI-agent adoption around a core requirement: agents should be known, trusted, and properly governed through identification, authentication, and authorization principles. Its February 2026 concept paper presents substantial implementation questions for public input rather than a settled, universal deployment model.
Those questions include how agents should be identified and authenticated; how keys should be issued, updated, and revoked; how authorization can change dynamically; how authority should be delegated or bound to a human; and how actions can be logged in tamper-resistant, verifiable ways.
The immediate significance is straightforward. An organization cannot apply least privilege or promptly revoke access if it cannot distinguish one agent from another. Nor can it establish meaningful accountability if the agent’s activity cannot be associated with the authority under which it acted.
The terminology around “AI attestation” requires restraint. The InformationWeek reporting describes attestation as a runtime-integrity assessment before an agent acts, considering factors such as configuration, memory or context, behavioral signals, and dependencies. The supplied material does not establish attestation as a universal industry standard or as a standardized cryptographic identity mechanism. Enterprises should therefore treat it as an emerging runtime-trust concept, not as a replacement for authorization design, monitoring, logging, ownership, or lifecycle controls.
MCP can enable connections; it does not govern the enterprise
The Model Context Protocol, or MCP, matters because it can provide a path for AI systems to access tools and resources. But a connection protocol is not a centralized governance program.
MCP authorization is optional. Where an implementation supports authorization, the specification calls for OAuth-based controls, requires servers to validate the intended audience for tokens, and recommends short-lived access tokens to reduce the potential impact of leaked credentials. Those are useful safeguards, but they do not resolve larger organizational questions: whether an agent should exist, who owns it, what business purpose justifies its access, or whether its accumulated permissions remain appropriate.
For IT teams, an inventory cannot stop at “we use MCP.” It needs to show each material agent-to-tool relationship and the authorization path behind it. Each connection should be reviewed as an integration with security consequences: what authority is granted, which data and actions are in scope, what event records are available, and how quickly access can be withdrawn.
Short-lived tokens may reduce the exposure window after a token is stolen. They do not correct an agent that was intentionally granted excessive access, nor do they solve the problem of an agent with no accountable owner.
Reported executive comments and verified company facts are different things
InformationWeek attributes comments about agent identity, sprawl, and governance to Atticus Tysen, Wally Dalrymple, and Ravi Soin. The executive identifications matter in a discussion centered on accountability.
Intuit identifies Atticus Tysen as its senior vice president and chief information security officer. Its public biography says he served as CIO before taking on the expanded role; describing him as a current CIO and CISO is not supported by the reviewed material.
The correct spelling is Wally Dalrymple. PSI identifies him as Chief Security Officer at both PSI and ETS, rather than CISO. Smartsheet publicly describes Ravi Soin as its CIO and CISO.
The report also attributes a detailed account of internal agent and MCP inventory practices to Smartsheet leadership. Separately, Smartsheet markets Smart Hub as providing oversight of organizational AI use, including role-based permissions and governance capabilities. That product description supports only a narrower capability claim. It does not independently verify that every Smartsheet internal agent and MCP endpoint is centrally cataloged, owned, and monitored. Readers should maintain that distinction: a reported executive description of internal practice, a vendor’s product claim, and an independently audited deployment fact are not interchangeable.
A practical lifecycle for agent governance
The appropriate response is not a blanket ban on agents. It is to place agents inside a disciplined lifecycle before their connections and authority proliferate.
Build an inventory that supports action
Record every production agent and every material prototype that can access organizational systems. At a minimum, include its business purpose, accountable owner, technical operator, connected tools or data sources, authorization method, permission scope, approval requirements, and emergency-disable path.
An inventory is not security by itself. Its value is operational: if a security team cannot locate an agent and its connections during an incident, employee departure, or application retirement, it cannot contain risk with confidence.
Separate sponsorship from the identity that acts
Every agent needs an accountable human or team sponsor, but it should not become an invisible continuation of one employee’s access. NIST’s focus on human-to-agent binding and delegated authority captures the challenge.
Organizations need answers to two related questions: who owns this agent, and under what authority may it perform each action? The answers may differ. An agent may support several approved users or a shared business process while still having one named team responsible for its continued justification and operation. What must remain possible is review and revocation.
Grant authority around specific work
Avoid making an agent a general-purpose administrator because it performs one privileged task occasionally. Where feasible, divide broad workflows into narrower actions and assign only the permissions each action requires.
High-impact outcomes deserve a human decision point. That can include actions that modify important records, change access, move sensitive data, or initiate consequential external activity. Human approval is not a substitute for sound architecture, but it is an important control when autonomous action would create unacceptable risk.
Retain downstream enforcement and meaningful logs
Connected applications should continue enforcing their own access policy. An agent request should not be assumed trustworthy merely because an upstream service allowed the connection.
Logs should allow an investigator to reconstruct meaningful events: which agent acted, under which authority, against which tool or resource, and whether the action succeeded. The NIST concept work points toward verifiable action logging, but organizations should not overstate their present assurance. The practical requirement is that records support investigation, access review, and revocation decisions.
Make retirement an operating process
Employee departure, contractor termination, project closure, and application retirement should all trigger agent review. The outcome should be deliberate: transfer the agent to a named owner, disable it pending review, or retire it permanently. Related credentials, delegated permissions, connectors, and tokens need the same treatment.
Periodic recertification is equally important. An agent with a sound purpose six months earlier may now have a new scope, new dependencies, a different owner, or no remaining justification for access. Lifecycle governance is how an organization discovers that drift before it becomes an orphan problem.
Microsoft Entra environments: map the control model to workload access
For Windows organizations using Microsoft Entra, agent governance should be integrated with existing identity operations rather than managed as a disconnected AI register. The key distinction is between a human sponsor and the workload or agent identity that reaches services. A sponsor is accountable for the business purpose and continued need. The acting identity—such as an identity an organization uses as a service principal or managed identity—needs its own documented permissions, technical ownership, and revocation path.
The supplied evidence does not establish which Entra features, access-review options, automation controls, licensing plans, or preview capabilities are available in a given tenant. Administrators should therefore verify their tenant’s licensing, feature status, scope, and product limitations before designing a control around a particular Entra function. No organization should assume that a feature described in a roadmap, preview, or separate product tier is universally available.
The governance implementation itself is still clear:
- Assign a named business sponsor and a technical operator to each workload or agent identity.
- Document which applications, tools, data sources, and permissions that identity can reach, along with the agent or workflow it supports.
- Do not rely on a departing employee’s account as the sole basis for a business-critical automation. Reassign approved ownership and authority explicitly.
- Put workload identities and associated permissions into a periodic access-review process. The review should test continued business purpose, appropriate scope, current ownership, and the need for each connected integration.
- Maintain an emergency revocation runbook that identifies who can disable the agent, withdraw its credentials or permissions, and halt related connections without waiting for informal knowledge from its original creator.
This does not imply that service principals, managed identities, or any other workload mechanism automatically solve agent governance. They are identities through which authority may be exercised. The remaining questions—who approved that authority, whether it is least privilege, how it is monitored, and how it is withdrawn—remain organizational responsibilities.
The resilience test is whether access can be explained and withdrawn
AI agents are likely to become useful infrastructure in Windows-centered workplaces, especially where employees rely on business applications, documents, collaboration services, and automated workflows. That usefulness increases the operational cost of unmanaged sprawl.
The immediate test for enterprise leaders is modest but demanding: can the organization identify every consequential agent, explain the authority behind its actions, restrict that authority to the necessary scope, observe what it does, and withdraw access promptly when ownership or purpose changes?
NIST’s concept work indicates that important details of agent identity, delegation, authorization, revocation, and auditability remain active implementation work. That uncertainty is a reason to avoid claims that any single protocol, product feature, or emerging attestation approach has solved the problem universally. It is not a reason to wait.
The organizations best prepared for AI orphans will apply established identity discipline now: named ownership, separate workload identities, least privilege, downstream enforcement, short-lived credentials where applicable, reviewable logs, periodic access reviews, emergency revocation, and a retirement process designed before an agent becomes indispensable.
