An employee connects a coding agent to a company system using a personal credential. Security discovers it, revokes the credential, and tells the employee to use the approved process.
The immediate exposure is addressed. The work is unfinished.
What should the employee do next?
If the answer is unclear, the organization has cleaned up an incident without resolving the access problem behind it. The task still needs to happen, and the shortcut is still attractive.
Discovery needs to lead somewhere: a supported way to get the work done.
The tool is only part of the problem
Shadow AI agents are agents used outside an organization’s approved oversight. But unmanaged access can exist inside an approved toolset too.
Approving Claude Code, for example, does not settle how it should connect to company systems. An employee might use a personal token. A team might share a service account. Neither decision is resolved by putting the agent on an approved list.
Consider an engineer investigating a production issue. The agent needs a repository, relevant tickets, and an internal API. Each connection raises the same questions:
Whose authority is the agent using?
What is it allowed to do?
How does that access end?
Without a supported approach, the engineer is left assembling one. Credentials go wherever the tools expect to find them, and the investigation moves forward.
That may be an attempt to get legitimate work done with the options available. Removing the credential addresses the exposure. Providing a usable alternative addresses one reason it was distributed.
Approval is not delegation
Two employees can use the same agent with different permissions. One employee can use several agents that need different levels of access.
A research agent may need to read information. An operational agent may need to make changes, with approval for sensitive actions. Neither should automatically inherit everything the employee can do.
The useful unit of control is specific:
This agent, acting on behalf of this user, performing this action.
That is where agent adoption becomes a privileged access problem. Privileged access management for AI agents governs which systems an agent can access, what it can do, whose authority it uses, and when that access ends.
An approved-tools list cannot express all of those relationships. Delegation can.
Give employees a supported path
An employee should be able to authorize an agent to perform permitted work without copying a provider credential into its environment.
Administrators define the boundaries. Users delegate within them. Sensitive actions require approval, and access can be withdrawn when it is no longer needed.
For the engineer investigating a bug, that might mean read access to a repository. The agent retrieves the information needed for the investigation. Permission to change code or repository settings remains a separate decision.
Duration matters as much as scope. A reusable credential can remain valid long after the investigation ends. Ending the agent’s access should not depend on trusting it to discard a copied secret.
Once a workflow is supported, employees should not have to solve credential storage, authorization, and audit logging every time they use it.
Delegation with built-in control
Alter gives organizations a way to let employees use agents across company systems while administrators control what those agents can access and do.
Employees authorize specific agents to work on their behalf within administrative limits. The same user can give different agents different permissions.
For requests routed through Alter, policy is enforced before the request reaches the underlying system:
Permitted actions proceed.
Sensitive actions can require human approval.
Prohibited actions are blocked.
Provider credentials are injected into delegated requests without being exposed to the agent. Audit records link activity to the agent and the user behind it. An agent’s delegation can be revoked without disconnecting the user’s underlying account.
This gives administrators a concrete answer when an employee asks to connect an agent: a supported way to complete the task, with enforceable limits on access.
The relevant requests need to flow through Alter. Separate credentials and direct connections still require discovery and remediation. The scoped-access guide shows how to establish that controlled path.
Make each finding improve the process
When security discovers unmanaged agent access, the next question should be why that path was used.
A missing integration needs an owner. An unclear approval process needs a defined route. Deliberate misuse needs investigation and containment.
An agent access policy should make the basics explicit: who owns each integration, what users may delegate, which actions require approval, when access expires, and how exceptions are handled.
Making approved access easier will not eliminate shadow AI. It gives employees a practical alternative to creating unmanaged access in the first place.
When you find a shadow agent, be ready to show its user a supported way to finish the job.
Two practical questions
How does discovery differ from access control?
Discovery identifies agents and their connections. Access control determines whether an agent may perform a particular action. An inventory provides visibility; enforcement requires controls in the access path.
Does expiring agent access mean expiring the underlying credential?
Not necessarily. An agent’s permission to use a stored credential through Alter can expire or be revoked while the underlying connection remains active. The delegation documentation explains that distinction.
If you’re interested, create an account on Alter and try delegated access with one of your agent workflows.