Agentic workforce governance needs visibility across every control point

At a glance

What this is: This is an analysis of how enterprise AI agents are creating a second workforce that current governance models cannot fully see or control.

Why it matters: It matters because IAM, NHI, and security teams now need to govern agent identities, tool access, attribution, and runtime action chains, not just human users and static service accounts.

By the numbers:

• About 1 in 8 exposed a tool that could execute code, delete data, or take an irreversible action on the first call.
• 84 percent of identifiable maintainers listed a single publisher, and most had no organization verification at all.

👉 Read Island's analysis of governing the enterprise AI workforce

Context

Enterprise AI agents are no longer isolated experiments. They are appearing inside normal workstreams, bringing their own tools, connecting to MCP servers, and operating beside human employees in ways that most governance programmes were never designed to track.

The core identity problem is visibility and accountability. If an agent can install tools, authenticate through borrowed credentials, and generate downstream actions that look human in the logs, then inventory, attribution, and access control all start to fail at the same time.

That makes this an NHI and agentic AI governance issue, not just an application security issue. The article is describing a control plane problem across browsers, endpoints, identities, gateways, and audit trails, which is now typical rather than exceptional in larger organisations.

Key questions

Q: What breaks when AI agents are connected through personal accounts or shared credentials?

A: Shared or personal credentials break accountability, lifecycle control, and revocation. If an agent inherits a human account, security teams lose clean ownership and cannot reliably attest what the identity can do or when it should be disabled. That creates an unmanaged backdoor into systems that may persist after the original setup is forgotten.

Q: Why do enterprise AI agents complicate NHI governance?

A: They complicate NHI governance because the security model was built around predictable non-human identities such as API keys and workload credentials. Agents reason over context, can chain actions, and may use multiple protocols in one workflow. That makes permission modelling necessary but insufficient, because the real control issue is whether the execution still reflects approved intent.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Who is accountable when an AI agent makes an unauthorised change?

A: Accountability should be assigned to the governance model that authorised the delegation, the owner of the workflow, and the team that set the policy boundary. In practice, organisations need clear responsibility for agent configuration, monitoring, and incident response because the machine’s speed does not remove human accountability for the delegated identity.

Technical breakdown

Why agent toolchains evade normal inventory controls

Agentic systems rarely stop at the model. They pull in MCP servers, IDE extensions, skills, hooks, and other tools that sit outside the catalogues many security teams maintain for users, devices, and SaaS apps. That creates a blind spot where the software can decide what to install or invoke at runtime, while the control stack only sees fragments. Natural-language tool metadata can also be unsafe even when code is not malicious, because the risk sits in instructions, not just binaries.

Practical implication: inventory must cover installed agent capabilities and tool metadata, not just endpoints and accounts.

Why agent attribution breaks conventional logging

When an agent authenticates as a service account or borrowed identity, downstream systems often record the human account rather than the actor that executed the sequence. That destroys reconstructability, which is the difference between having logs and having evidence. The identity problem is amplified when agents keep standing credentials, because the same token can later be reused by either the agent or an attacker. A usable governance model needs the agent to have its own identity boundary, even if it acts on behalf of a person.

Practical implication: separate agent identities from human identities and preserve action-level attribution at the point of execution.

Why agent behavior is a chain, not a single event

An agent session is a sequence of decisions and tool calls, not one monolithic action. Prompt, model output, tool selection, returned data, file access, and outbound calls form a chain that no single security control sees end to end. That is why one control may catch the login, another the network request, and another the SaaS call, while none understands the whole incident. In practice, detection has to move inline and follow the chain, because post-event reconstruction arrives too late.

Practical implication: monitor prompts, tool calls, and returns inline so the chain can be interrupted before impact.

Threat narrative

Attacker objective: The attacker wants the agent to recommend, install, or execute malicious tooling so they can abuse trusted automation paths and expand access without traditional user compromise.

1. Entry occurs when an attacker plants or exposes a malicious MCP server or similar agent-capability lure so the agent discovers it during normal tool lookup.
2. Escalation follows when the agent installs or invokes the capability and the attacker gains a path into the agent's operating context, often through trusted recommendations or borrowed credentials.
3. Impact occurs when the agent executes attacker-influenced actions, leaks data, or performs irreversible operations that appear legitimate in downstream logs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic governance fails when organisations assume work can be governed one login at a time: the article shows a second workforce operating with its own tools, timing, and execution paths. That assumption was built for human-paced workflows and static entitlement models. When agents can bring, chain, and invoke tools in-session, the implication is that governance has to move from account review to action-chain oversight.

Identity does not select or combine tools dynamically mid-session was designed for a constrained, human-operated workflow. That assumption fails when an agent can discover, install, and invoke capabilities on the fly without a new approval step. The implication is not just more control, but a different premise for least privilege and authorisation design.

Agent attribution collapse is a lifecycle failure, not just a logging defect: the article describes agents acting through service accounts, which makes the human and machine identities indistinguishable in downstream evidence. That breaks joiner-mover-leaver logic for non-human identities because the system cannot tell who actually acted. Practitioners need to treat agent identities as first-class governed subjects, not as borrowed context.

Runtime governance is now the defining NHI boundary for AI agents: the most important controls are no longer limited to provisioning and rotation. They must inspect what the agent can do right now, what tool it just loaded, and whether the action is still within policy. That is the practical dividing line between visible automation and ungoverned agentic behaviour.

Identity blast radius is now the correct metric for agent risk: when one agent can touch multiple tools, systems, and data paths, the question is not how many identities exist, but how far a single identity can move before a human notices. That shifts the governance conversation from credential count to executable scope, which is where practitioners should focus.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access becomes governance debt.
• Track the shape of the blind spot with Top 10 NHI Issues to align discovery, identity, and lifecycle controls.

What this signals

Agentic identity governance will increasingly look like runtime policy enforcement, not periodic review. Once agents can install tools and act across systems in a single session, access review cadences lose their enforcement value unless they are paired with live telemetry. Teams should expect the control conversation to shift toward inline inspection, session-scoped authorisation, and stronger evidence chains across browser, endpoint, and gateway layers.

Identity blast radius will become a more useful planning concept than credential count. An agent with one identity but broad tool reach can create more governance exposure than many tightly-scoped non-human accounts. The practical response is to measure how far one agent can move, what it can invoke, and how fast it can do it before detection.

The growth of agentic workers also means IAM, PAM, and NHI programmes have to converge operationally. Human workflows, service accounts, and autonomous tool use now share the same infrastructure, so the reader's programme should prepare for common policy enforcement, shared audit evidence, and differentiated identity treatment by actor type.

For practitioners

• Map every agent capability to a governed inventory Track agents, MCP servers, IDE extensions, hooks, and skills as part of the identity estate. Require the inventory to show what each agent can invoke, which endpoints it can reach, and whether the capability can be removed in real time.
• Issue separate identities for agents and humans Stop relying on borrowed human credentials for agent activity. Give each agent a distinct identity boundary, then enforce task-scoped access so attribution survives investigation and offboarding.
• Block standing credentials for agent workflows Move agent access behind a gateway that brokers just-in-time access and keeps raw API keys out of the agent session. This reduces credential reuse and narrows the window for hijacking or replay.
• Monitor the full action chain inline Inspect prompts, tool calls, returned payloads, and outbound actions in sequence rather than relying on log review after the fact. Inline enforcement is the only way to stop agent chain abuse before impact.
• Treat risky tool metadata as a security control issue Review natural-language instructions, install prompts, and repository metadata with the same seriousness as executable code. If the metadata can instruct an agent to act silently, it is part of the attack surface.

Key takeaways

• AI agents create a second workforce whose tools, identities, and actions cannot be governed reliably with human-centric controls alone.
• The evidence points to a broad visibility gap, from published MCP server risk to agent activity that disappears into borrowed credentials and fragmented logs.
• Practitioners need runtime inventory, separate agent identities, and inline action-chain controls if they want attribution and containment to hold.

Key terms

• Agentic Workforce: A population of AI agents that operate inside an enterprise as autonomous actors with roles, access, and action authority. Unlike simple automation, these systems can choose tools, sequence tasks, and trigger downstream work. That makes them identity subjects that require governance, monitoring, and lifecycle control.
• Action Chain: The action chain is the full sequence from request origin to policy evaluation to permission use to downstream effect. For agents, it matters because risk is created by the complete runtime path, not just by the initial authentication event or the existence of a connector.
• Identity Attribution: Identity attribution is the ability to determine which entity performed an action and under what authority. For AI agents, it requires separate identities, structured logs, and traceable decision records so investigations can distinguish human intent from autonomous execution.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

What's in the full article

Island's full blog post covers the operational detail this analysis intentionally leaves for the source:

• How Island maps agent activity across browser, endpoint, network, and gateway control points
• Examples of inline enforcement for prompts, tool calls, and returned payloads in agent workflows
• The operational model for just-in-time access when an agent needs to reach multiple tools
• Why the vendor frames agent onboarding as a workforce governance problem rather than a point solution

👉 Island's full post covers the visibility gaps, agent control points, and governance model in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.