Three notices in the same week: Red Hat's CTO explains that securing an agent means securing the identity, runtime, and network around it; Okta devoted its Oktane conference to treating agents as first-class identities; and Delinea's report on the gap between policy and enforcement found that nearly every company has an access policy for its agents, even though the security team does not always enforce it across systems.
If you are preparing an agent pilot, this detail affects you more than the choice of model. An agent that only answers questions makes mistakes that stay inside the conversation. One that creates orders, moves records, or writes to your ERP multiplies every failure. Gartner estimates that four in ten enterprise applications will carry task-specific agents before the end of 2026, so system access is becoming a business decision.
The permissions it inherits
The usual pattern in pilots: the agent runs on a person's token or a shared service key. That starts fast, and it inherits every permission that person has. If the agent that prepares order confirmations signs in with an operator's credentials, it can read everything she reads: payroll data if the ERP stores it, supplier bank details, whatever sits there. A malicious message that reaches its context (an email, a ticket) can be enough to make it query what it should not.
The trail looks just as bad. Your logs will say the operator queried the payroll table at three in the morning. No one will be able to tell what the agent did and what the person did, and revoking the agent's access means cutting off the person who used it. A Gravitee survey published in February puts numbers on this: only two in ten teams give the agent its own identity; the rest share keys or issue generic tokens.
Own identity and least privilege
The fix the industry is standardizing: each agent with its own identity, and the person as a separate one. When the agent acts on your behalf, the token carries both: who delegates and who executes. That answers the questions an auditor will ask: who requested the action, which agent performed it, and under what permission.
The second control is the principle of least privilege. You give the agent access to the process it automates, and no further: if its job is to look up orders, it does not touch suppliers or payroll. Identity providers already ship support for this (Microsoft's Entra Agent ID, agent identities in Okta, dedicated OAuth profiles in the MCP protocol), so your team's work is to define boundaries and review them.
And the third: short-lived credentials and human approval for anything irreversible. A token that expires in minutes limits the damage of a hijacked session. A human threshold (above a certain amount, any deletion or change to master data) keeps an agent's mistake from turning into an incident.
What to review before you connect the agent
Before you grant access, your team can run through this list:
- What identity does it use? If the answer is a person's token or a shared key, that is where the fix starts.
- What can it do, beyond what it can read? Limit tools and resources to the specific process, and review the scope whenever the process changes.
- What does it do without asking? Irreversible actions call for human approval and a log.
- If it starts behaving oddly tomorrow, how fast can you cut its access without affecting anyone else?
Delinea found that nearly every company surveyed has a policy on what data its agents can access; the same report measures the distance between that policy and what is actually enforced. That distance closes with identities, scoped permissions, and logs: the same access-control work you already do for the people on your team.
At Luxion we connect agents to real systems (ERP, e-commerce, support) and build that control from day one: the agent gets its own identity, permissions limited to the process, and human approval where it matters. If you want to see it on one of your processes, we prepare a prototype connected to your data and have it running in a few weeks.