The control breaks when inventory, ownership, and access evidence live in different places. Teams can see an agent in one console, its configuration in another, and its activity in logs elsewhere, which makes recertification and offboarding unreliable unless those records are joined into one governance view.
Where the governance break happens
These setups fail at the control plane, not just the UI. If the team can discover an agent in one Microsoft console, inspect its settings in another, and only prove activity through a third log source, then no single owner can reliably answer basic governance questions fast enough for review, exception handling, or retirement. The result is fragmented evidence, inconsistent decisions, and weak accountability.
That fragmentation matters because governance depends on joining three facts: what exists, who owns it, and what it can do. When those facts are split across consoles, the organization may still have the data, but it no longer has a dependable control process. The Shadow AI and AI Agent Discovery Guide is useful here because discovery is the first prerequisite for any inventory that can later be governed.
In practice, the break is usually a records problem. An agent can be configured by one team, used by another, and observed only through telemetry that never gets linked back to the accountable business owner. That is why recertification becomes slow and offboarding becomes incomplete: the reviewer is validating partial evidence rather than a single authoritative record. For the same reason, the AI Agent Observability, Audit and Incident Response Guide is relevant when you need to turn scattered activity into attributable evidence.
Why separate consoles weaken recertification and offboarding
Recertification depends on repeatable questions: who owns this agent, what data and tools can it reach, and when was that access last validated? If those answers live in different products, the review process turns into manual correlation, and that is where errors start. Teams miss stale agents, confuse similar names, or approve access because the evidence is inconvenient to assemble rather than because it is actually current.
Offboarding fails for the same reason. Retiring an agent is not just deletion, it is a coordinated end to ownership, credentials, connectors, delegated permissions, and any downstream automation that depends on it. When the lifecycle record is split, one console may show the object removed while another still shows usable access. The Agentic AI Identity Guide covers the ownership and retirement side of that lifecycle, while the AI Agent Authorisation Guide is relevant for understanding how delegated access should be scoped and withdrawn.
The practical consequence is that the organization cannot prove what was approved versus what remains active. That gap is especially visible when approvals, configuration, and runtime logs are each owned by different teams. A healthy process should let one reviewer answer whether the agent still exists, whether it still has standing access, and whether its recent actions match its approved purpose.
What a joined governance view must show
A usable governance view does not need to eliminate every source system, but it must reconcile them. At minimum, the control record should tie together the agent identifier, business owner, technical owner, configuration state, permission scope, and the activity trail used for review. If those fields cannot be joined reliably, then the organization is not governing the agent, it is merely collecting fragments about it.
That joined view should also separate human approval from machine execution. In many environments, a console may show that an agent was created or modified, but not whether that action was still within the approved operating envelope. Good governance therefore depends on linking inventory with authorization evidence and telemetry, not treating any one of them as sufficient on its own. The AI Agent Identity Security Buyer’s Guide can help teams evaluate tooling that is intended to connect those control points rather than leaving them siloed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Separate consoles can leave agents partially retired and still active. |
| NHI-05 — Overprivileged NHI | Fragmented governance hides excessive agent permissions across systems. | |
| Recommendation — Join owner, config, and access records so agent retirement revokes every active path. Review agent entitlements against one authoritative inventory before recertifying access. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Scattered logs must be correlated to support meaningful review and accountability. |
| IA-5 — Authenticator Management | Agent credentials and tokens need unified lifecycle control across consoles. | |
| Recommendation — Correlate agent activity logs into one reviewable audit trail. Track and rotate agent authenticators from one governed lifecycle process. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The subject depends on consistent identity records for agents across systems. |
| A.5.18 — Access rights | Recertification and offboarding fail when access evidence is split across consoles. | |
| Recommendation — Maintain one authoritative identity record for each agent and its owners. Reconcile and revoke agent access from the authoritative access register. | ||
| CIS Controls v8 | CIS-5 — Account Management | Agent ownership and removal are an account lifecycle problem at scale. |
| Recommendation — Centralize agent account lifecycle checks and deprovisioning evidence. | ||
Practitioner Guidance
What to verify: Before trusting a governance process, verify that every agent record resolves to one owner, one permission source of truth, and one auditable activity trail. If any of those three are split, recertification is already operating on incomplete evidence.
Decision rule: If an agent can be created, configured, and observed in separate consoles without a shared identifier, treat that as a governance defect, not a reporting inconvenience. The control is only reliable when the record can be joined end to end.
What to prioritise: Fix the ownership and offboarding path first, then reconcile configuration and logging. That sequence reduces the chance of approving or retaining agents that no longer have an accountable business purpose.
Practitioner takeaway: The key failure is not the number of consoles, it is the absence of a single governable record that survives across inventory, access, and activity.
Related resources from NHI Mgmt Group
- What breaks when Microsoft 365 security is managed with disconnected tools across many customer tenants?
- What breaks when user and group access is managed manually across Microsoft Entra ID and Tailscale?
- How should security teams make NHI best practices usable across the business?
- How should organizations approach the governance of AI agents?