AI agents are becoming non-human actors with permissions, telemetry, suppliers, and blast radius. If they remain invisible, they are already an unmanaged workforce inside the enterprise.
Related Big Read: The shadow agent problem: why machine identity is now the perimeter
AI agents are moving from interface to workforce. That does not mean they are employees. It means they occupy the same control problem as employees: they can be assigned work, granted access, connected to systems, observed through activity, and removed or constrained when risk changes. If they are unmanaged, they create the same kind of exposure as shadow IT, but with a sharper edge. They are shadow agents. And shadow agents are shadow workforce risk.
What’s recently changed?
Microsoft’s Agent 365 and Entra Agent ID announcements matter because they formalise a category that many organisations had been treating as a feature problem. Agents are non-human actors that need discovery, identity, policy, ownership, permission scoping, monitoring, and revocation. That shift changes the conversation. The question has moved to: does your organisation already have non-human actors operating without the controls expected for privileged human users?
The wider risk pattern
The issue-week evidence points to a larger control surface. DeepSeek-R1’s security-behaviour degradation raises questions about model provenance and alignment choices. Claude misuse in cyber operations shows that public-model safety filters cannot be treated as enterprise control boundaries. The Mixpanel/OpenAI metadata exposure shows that AI telemetry and analytics partners can become part of the attack surface. Qilin targeting of managed service providers reinforces the old lesson that attackers like multiplicative access paths. None of these stories is only about a model. They are about the systems around the model: identity, tooling, telemetry, vendors, and permissions. That is where agent governance has to live.
Why "shadow AI" is too soft a term
Shadow AI is useful as a discovery label. It is too soft as a risk label. An unapproved chatbot used for drafting is one kind of issue. An unregistered agent with access to email, CRM, documents, tickets, code repositories, or finance workflows is different. The second case is unmanaged delegated authority. The agent may have a human sponsor, but that sponsor may not understand the permission footprint. It may have a vendor owner, but that vendor may not carry the business accountability. It may inherit a user’s access, but the user may not see what the agent does at runtime. It may produce logs, but those logs may not distinguish human action from agent action. That is why the workforce analogy matters. If a contractor joined the business, leaders would expect onboarding, role definition, access approval, supervision, and offboarding. Agents with execution authority require at least that level of discipline.
The framework
Use this framework to govern non-human authority before it becomes invisible operational risk.
01
1. Inventory: know the non-human workforce
The first question is not whether an agent is approved.
The first question is whether it is known.
Organisations need a live inventory of AI agents, bots, copilots, automations, and agentic workflows. That inventory should separate experimental assistants from systems with execution authority. It should identify owners, purpose, access scope, model dependencies, connected tools, telemetry partners, and review cadence.
The point is not administrative neatness.
It is to stop invisible authority from accumulating.
02
2. Identity and access: stop letting agents borrow people
Agents should not simply act as the user who created them.
Borrowed human authority creates a control problem. The agent inherits permissions that were granted for human judgement, human context, and human accountability. It may also inherit historic access that nobody has reviewed in months.
Mature governance gives agents their own identities or service principals, with narrower scopes than their creators. High-consequence workflows need stronger boundaries than read-only summarisation. Approval, export, modification, deletion, and downstream triggers should be treated as separate authority classes.
03
3. Observability: distinguish agent action from human action
Logs that cannot distinguish agent behaviour from human behaviour are not enough.
Leaders need to know which agents can approve, export, modify, or trigger downstream actions. Security teams need activity trails that identify the non-human actor, the supervising human or owning team, the system touched, the data category involved, and whether the action matched the expected workflow.
If a policy says agents must be supervised, the logs should show what supervision means.
04
4. Provenance and supply chain: govern the stack around the agent
An agent is a model, toolchain, prompt layer, retrieval path, integration set, telemetry stream, hosting environment, and vendor relationship. The Mixpanel/OpenAI incident is a reminder that metadata can be sensitive. A telemetry provider may not hold prompts or API keys, but it may reveal usage patterns, customer identifiers, product adoption, and targeting information.
Model provenance also matters. Alignment choices, training practices, regional constraints, vendor updates, and model substitutions can affect behaviour in ways that ordinary application reviews do not capture.
For agentic systems, supply-chain review is not a procurement appendix.
It is part of the trust boundary.
05
5. Revocation: prove control by taking it away
The most important test of agent governance is whether access can be narrowed or removed.
Can the organisation pause one agent without disabling a platform? Can it revoke a token without breaking unrelated workflows? Can it reduce scope when risk changes? Can it preserve logs and reconstruct what the agent did? Can it decommission an agent when the business owner leaves or the workflow is retired?
Revocation is not the final step.
It is proof that identity governance is real.
Control rule
If the organisation cannot identify, scope, observe, and revoke its non-human actors, it should not treat agentic authority as governed.
The executive test
Ask this in the next AI governance meeting:
Which non-human systems in our environment can act, approve, export, modify, or trigger work on our behalf?
Then ask:
- Do they have their own identities?
- Do they have named owners?
- Are their permissions narrower than the people who created them?
- Can we distinguish their actions from human actions in logs?
- Do we know which models, vendors, and telemetry partners sit in their trust boundary?
- Can we revoke or narrow their access quickly?
If the organisation cannot answer those questions, its AI governance is still language.
It has not yet become control.
Why this is a board issue
Boards and ELTs do not need to manage agent inventories directly.
They do need to insist that management can evidence control over non-human authority. Agentic workflows will be sold as productivity, automation, and scale. Some of that value is real. But value does not remove the need for traceability.
The leadership obligation is to ask whether the organisation can demonstrate:
- who or what is acting
- under whose authority
- against which data
- through which tools
- with what monitoring
- with what revocation path
That is a central Synoptikon thread.
Evolution of shadow agents and workforce risk
In Agent identity as the control boundary, an early question was asked: if an agent can act, how should it be identified and constrained?
Shadow agents as shadow workforce risk moves the conversation forward. The agent is no longer just an emerging identity concern. It is part of a non-human workforce that needs the same basic disciplines as any other source of enterprise authority: inventory, ownership, access scope, supervision, provenance, and offboarding.
The control boundary is still identity.
The operating problem is now workforce governance.
