An administrator role is not a security policy for an AI agent
Why Identity Governance, the Secret Vault and Runtime Authorization have to work together. An Autonomous AI Agent must not inherit the power attached to the technical role the application forces us to assign it; it must only be granted the ability to perform the action it was created for.
A CRM export, an agent, and a role that overreaches
We use Autonomous AI Agents ourselves to automate some of our internal operations. An authorised colleague can send a request from a simple conversational interface — Telegram, WhatsApp — as a plain sentence such as "prepare the daily CRM export and send it to the reporting tool". Behind that sentence, the agent has to understand the task, pick the useful tools, query the CRM, generate the export, check its format, hand the result to the target application and report success or failure.
The secrets needed for those connections are not written into prompts or messages. They live in a Secret Vault. Wherever possible, the agents use OAuth 2.0 access limited to the strictly necessary OAuth Scopes. Secrets and tokens are delivered to the technical component in charge of the call — a Credential Broker — without being exposed to the model or to the messaging user. This architecture significantly reduces exposure. It does not, on its own, close every gap.
The export must only contain the fields useful for reporting: opportunity id, status, amount, forecast date, sales owner and a handful of reporting attributes. It must not carry confidential notes, unnecessary personal contact details, attachments, technical secrets, data from other CRM objects or the full history. On paper, the task is simple. Reality shows up at the CRM integration point. The application does not necessarily offer a right named "export only these six fields, once a day, to this destination". It exposes broader roles — user, manager, integrator, administrator — and, in the case at hand, the export API requires the administrator role.
Identity Governance can govern the assignment of that administrator role. It cannot invent a granularity the application does not expose. It cannot turn a coarse application role into a narrow export permission when the application itself has no way to express it. This is exactly where the conversation shifts, and where runtime Fine-Grained Authorization earns its place.
Agents explore tools, not the intentions of the organisation
An autonomous agent does not always replay a fixed sequence. To reach the goal it has been given, it may compare several methods, explore the tools it has been offered, read available documentation, probe an endpoint, adjust a request after an error, pick a different path, chain several actions or retry with different parameters. That is precisely the capability that makes it valuable: it lets the agent find an efficient way to carry out the mission without a developer scripting every step.
That same capability reshapes the way we think about security. With a classical script, we inspect the code that was written. With an autonomous agent, what we mostly have to master is the space of actions it may choose to explore. The risk does not come from a hostile intent; it comes from the agent's ability to look for a solution inside the technical perimeter that has been opened to it.
We do not just secure the path we imagine the agent will take. We secure every path its tools allow it to take. That principle drives the architecture, the way policies are written and the choice of enforcement point. It also explains why an instruction inside a prompt does not play the same role as a technical control enforced by a component outside the model.
Six statements we hear, six questions we keep asking
We hear the same phrases across most agent-based automation projects. Each contains a share of truth. None, taken in isolation, is enough to protect the mission.
- 01
"Our IGA governs the AI agents"
An Identity Governance platform can create the Agent Identity, assign an owner, provision the account, drive the lifecycle, grant a role, run recertification and revoke access when the need is over. That is useful and necessary. We then ask another question. What happens once the agent has received the administrator role? Can it call only the export API, or can it also delete an opportunity, create another administrator, alter CRM settings, read every record, download all attachments, change automation rules? If the answer depends solely on the role configured in the CRM, IGA cleanly covers the granting of the right without narrowing its usage. Cleanly governing an administrator role does not make that role any less administrator.
- 02
"OAuth already enforces least privilege"
OAuth brings essential protection. The agent does not need to know a user's password: it receives an Access Token that is time-limited, bound to a specific API, tied to identified Client Credentials, restricted to selected scopes and revocable. We favour that approach whenever the application supports it. The quality of the Least Privilege it delivers depends, however, on the granularity of the scopes exposed by the target application. An API may offer `crm.read`, `crm.write` and `crm.admin` without ever exposing `opportunities.read.selected-fields`, `export.once-per-day`, `send-only-to-reporting-platform`, `deny-attachments` or `deny-user-administration`. If the export requires `crm.admin`, the token is correctly capped at the smallest available scope, yet that scope remains too broad for the actual mission. The smallest scope the vendor offers is not always the minimum privilege the business process actually needs. OAuth does what it is designed to do; the limit sits in the authorization model of the target application.
- 03
"Secrets are in a vault, so the risk is handled"
Keeper — or another Secret Vault — protects the essentials: client secrets, Refresh Tokens, API keys, certificates, technical passwords. The secret is not pasted into Telegram, WhatsApp, a prompt, a configuration file or a code repository. A trusted component, the Credential Broker, retrieves the secret or exchanges the refresh token for a temporary access token, and the agent then uses the connection without handling the raw secret. The vault covers storage, distribution, rotation, revocation and audit of the secret's use. It does not automatically govern every action the resulting token allows. Once a valid administrator token has been issued, the fact that its underlying secret is perfectly protected does not stop that token from being used for an unintended action. The vault protects how the power is obtained. It does not, on its own, define how that power will be exercised.
- 04
"The prompt says it, so it is enforced"
A prompt may spell out "export only opportunities and never modify the CRM". The instruction is useful; it describes the expected behaviour. It is not a security boundary. The agent may misread an instruction, pick a tool that is too powerful, call a different endpoint after an error, ingest external data that carries an ambiguous instruction, choose a technically valid but unintended method, or issue a request with a broader scope than needed. The prompt expresses intent. The authorization policy sets the limit. A guideline the agent can interpret is not equivalent to a prohibition it cannot bypass.
- 05
"Our solution does PBAC for agents"
A platform can indeed evaluate a PBAC policy for an agent. We then ask where the Policy Enforcement Point sits and whether the agent can bypass it. If the agent directly receives the client secret, the refresh token, the administrator access token and the CRM API endpoint, and can freely call that API, a policy evaluated elsewhere does not truly limit its power. Every sensitive action has to travel through a PEP — API Gateway, tool proxy, intermediate service, capability broker, component embedded in the agent orchestrator. A policy the agent can go around is not an authorization policy. It is a usage guideline.
- 06
"There is a human in the loop"
That sentence comes up often. We ask which actions actually require an approval, how the approver's identity is verified, when the validation happens, and what the agent does when the validation does not arrive. A command sent from Telegram or WhatsApp carries a human intent; it does not replace the authorization control. For a sensitive action, the policy may require a user belonging to an authorised group, a request within a defined time window, a confirmation, a dual validation, execution limited to a specific environment, and a justification kept in the log. The simplicity of the interface must never be mistaken for simplicity of the security decision.
An AI agent architecture is not judged by the list of controls it advertises. It is judged by the action the agent can still perform when each of those controls is bypassed or misinterpreted.
A five-link chain, no single link is enough
In the CRM export scenario, the agent requests the "CRM Export" tool, the tooling component identifies the agent and the context, the policy allows or denies the action, the broker fetches the secret from the vault, obtains an OAuth token, executes only the authorised call, may filter fields, ships the result to the approved destination, records an audit trail, and the token expires or is destroyed. The agent never gets an administrator access it could reuse outside that chain. Each component plays a defined role — and none of them is sufficient on its own.
- Netwrix Identity Manager
- Netwrix Identity Manager governs the agent's identity in the same way it governs a human's: explicit name, purpose, business owner, technical owner, source application, target application, criticality, creation date, lifetime, modification and suspension processes, review date, justification for each entitlement. It determines that the agent legitimately exists, belongs to the CRM export process, may obtain the required application role, must be recertified, must be decommissioned when the process disappears and must not reuse its rights for a different mission. It governs the fact that the agent can obtain the right. It does not automatically translate a coarse application right into a precise business permission.
- Keeper
- Keeper protects the secrets that make the connections possible — client secrets, refresh tokens, API keys, certificates, technical passwords. The secret is stored, delivered and rotated under control. It is never injected into a prompt or forwarded through the messaging channel. The vault does not, however, decide whether the API call performed with the token matches the agent's purpose: that decision has to be taken elsewhere, on the mandatory path of the call.
- OAuth and Access Management
- OAuth lets us hand the agent or the broker a temporary token without sharing a password. Scopes are constrained as far as the application permits. Ping Identity, Microsoft Entra ID, Keycloak or the application's own mechanisms may issue and manage those tokens depending on the architecture. Delegated Authorization cleanly covers Machine-to-Machine Access. Effective granularity, however, remains bounded by what the target API exposes.
- Axiomatics
- Axiomatics carries the Runtime Authorization. The policy combines the agent's identity, its owner, its purpose, the requested action, the resource, the destination, the time window, the volume, the data classification, the human requester and the environment. The engine can deny delete endpoints, write operations, user administration, attachment reads, unnecessary fields, an unapproved destination, an export triggered outside the allowed context, an abnormal volume, or an action lacking an identifiable owner or requester. It only truly protects the action if its decision is enforced on the mandatory path of the call.
- The tool proxy or API Gateway
- This is the Policy Enforcement Point. It intercepts actions, restricts endpoints, filters parameters, injects the token, strips forbidden fields, imposes the destination, caps the volume, blocks write operations and logs the execution. It is what turns a policy decision into an effective control. Without it, the policy stays an intention. The application role defines what the account could do; the runtime policy, enforced at this point, defines what the agent is allowed to do in this specific execution.
Three layers of least privilege
The least privilege of an agent is not just about picking the smallest role in an application. It reads on three layers that must all be held together. First layer, the identity: the agent has its own Non-Human Identity, it does not reuse a colleague's account, its owner and purpose are known. Second layer, secret and token: the secret sits in a vault, the token is temporary, the scopes are reduced to what the application allows. Third layer, the action: the runtime policy restricts endpoint, resource, fields, destination, timing, volume and purpose.
Take a concrete scene. The agent tries the planned export endpoint. The API returns a pagination error. The agent reads the available documentation and discovers an administrative endpoint that would generate a complete export more easily. From the goal's perspective, that method looks efficient. From the governance perspective, it is unacceptable — it pulls more data than needed. A fixed script would have simply failed; the agent finds another way. That is precisely its value. The runtime policy therefore has to permit the expected business outcome without opening every technical path that might reach it. The PEP denies the administrative endpoint. The agent stays inside the authorised tool, or it reports that it cannot finish the task. A clear response saying the task cannot be completed within the authorised perimeter is preferable to a success obtained through an uncontrolled path.
For an autonomous agent, "mission accomplished" is not a sufficient security criterion. The path used matters as much as the outcome. Least privilege for an agent is not measured by the role attached to its account. It is measured by the most powerful action the agent can actually perform.
Back to the CRM export, one last time
The agent identity is governed in Netwrix Identity Manager. Its OAuth secret is protected in Keeper. The issued token carries the narrowest scopes the CRM knows how to expose. Because those scopes stay too broad, the agent does not directly receive the corresponding power: it goes through an enforcement point. Axiomatics evaluates the policy at the moment of the action. The proxy only allows the export endpoint, the intended objects, the necessary fields, the approved destination and the authorised context. Any other action is denied, even though the account's administrator role would technically make it possible.
We do not add PBAC because the agent uses artificial intelligence. We add it when the application's rights model is incapable of expressing the limit the business needs. A plain script, a properly scoped API and a read-only token are enough for many use cases. Runtime Authorization becomes necessary when the agent chooses its own execution path, when its tools are powerful, when the application imposes a role that is too broad, when several data sources are reachable, when the information handled is sensitive, when the destination of the data has to be controlled and when the purpose of each action has to be demonstrable.
To secure an autonomous agent, we do not merely ask which role its account holds. We work out the most powerful action it can actually perform when no one is watching.