How should organisations govern agent identities that belong to a business unit?

They should assign clear Sponsorship for lifecycle accountability, a Manager for day-to-day reporting and access-package requests, and an Owner for technical administration. The point is to avoid overlapping authority while making sure every object in the chain has someone answerable for it.

Why This Matters for Security Teams

When an agent belongs to a business unit, the governance problem is not just “who owns the account.” It is who can approve risk, who can answer for misuse, and who can change controls when the agent starts calling tools, moving data, or chaining actions. Without clear Sponsorship, Manager, and Owner separation, access reviews become theatre and offboarding often fails. That matters more for agents than for ordinary service accounts because their behaviour can expand quickly across workflows and systems.

Current guidance suggests treating the business unit as the accountable home for operational use, while security retains enforcement authority over policy and monitoring. This is consistent with the runtime risk focus in the NIST AI Risk Management Framework and the attack-path concerns highlighted in OWASP NHI Top 10. NHI Mgmt Group has noted that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is why ownership clarity is a control issue, not an admin preference. In practice, many security teams encounter broken accountability only after an agent misuses access or survives a business-unit reorg.

How It Works in Practice

The cleanest model is to separate business accountability from technical control. Sponsorship should sit with the business unit leader or delegate who accepts the risk of the agent’s purpose and funding. The Manager should handle operational reporting, access-package requests, and periodic attestation. The Owner should control the technical object, including configuration, secrets, integrations, and revocation. That separation helps prevent one person from approving, operating, and administering the same identity without oversight.

For agent identities, that structure should be backed by workload identity and time-bounded access rather than informal trust. As agentic systems often behave dynamically, static role assumptions are weak. Runtime authorisation, JIT credential issuance, and policy-as-code are a better fit because the agent’s access should be evaluated based on the task at hand, not a one-time role assignment. This is the direction reflected in OWASP Agentic AI Top 10, CSA MAESTRO agentic AI threat modeling framework, and SPIFFE-style workload identity patterns.

• Sponsorship approves purpose, risk acceptance, and lifecycle funding.
• Manager owns periodic review, access requests, and exception escalation.
• Owner administers the identity, secrets, and technical revocation actions.
• Security defines the policy baseline, telemetry, and incident triggers.

This works best when every agent has a named business purpose, a unique identity, a short-lived credential strategy, and a documented offboarding path that is tested before deployment. These controls tend to break down when one agent is reused across multiple business units because accountability, access review, and revocation all become ambiguous.

Common Variations and Edge Cases

Tighter identity governance often increases administrative overhead, requiring organisations to balance accountability against delivery speed. That tradeoff is real, especially when a business unit wants rapid experimentation or when multiple teams share the same automation platform.

One common edge case is a federated platform team running agents on behalf of several business units. Current guidance suggests the platform team can be Owner for technical administration, but each business unit still needs its own Sponsor and operational Manager. Another variation is vendor-operated agents, where the external provider may host the runtime but must not own business risk acceptance. In those cases, the customer should retain Sponsorship and require explicit evidence of control alignment, especially for secrets handling, access boundaries, and revocation procedures.

There is no universal standard for this yet, but best practice is evolving toward clear RACI-style assignment plus machine-enforced controls. That means the identity object, its secrets, and its authorisation policy must all be traceable back to the business unit that benefits from the agent. It also means event-driven deprovisioning matters: if the sponsor changes, the agent should not keep inherited permissions by default. The risk patterns described in CoPhish OAuth Token Theft via Copilot Studio and the broader evidence in the Ultimate Guide to NHIs show why unclear ownership turns into exposure quickly, especially where third-party integrations and long-lived tokens are involved.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• How can organisations govern AI agents that use service accounts and tokens?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between human identity governance and AI agent governance?