COMMENTARY: For years, enterprises have been able to get away with a loose model for non-human identities (NHIs). Create a service account. Issue an API key. Store a secret. Rotate it periodically.
This approach was never ideal, but it was manageable when the software using those credentials performed predictable tasks. AI agents change the equation. They do not call one API or run one scheduled job. They can interpret instructions, invoke tools, hand work to other agents, access multiple systems and take actions on behalf of people or business processes.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
A service account tells us an identity has access, but not whether the agent using that access is the correct agent, running in an authorized environment, under the right policy, for the right purpose, at the right moment.
That’s why enterprises need a more practical identity model for agents. Better to use a passport and visa analogy.
Why agents need passports
A passport proves an entity is known and recognized. A visa grants permission to do something specific, in a specific context, for a limited time.
The passport represents the agent’s durable identity: Is this agent allowed to operate in our environment at all?
Think of the visa as the agent’s just-in-time authority: What can it do right now, on whose behalf, for how long and under which policy?
A bearer token can get stolen, anyone can reuse a password, and a service account can accumulate privilege over years.
We can’t think of an agent passport as simply another secret. We have to ground it in workload attestation: where the agent runs, what runtime it uses, whether the container gets signed, whether it’s a trusted environment, what capabilities it declares, and whether those claims are continuously verified.
In other words, the passport should prove that it’s a known agent, expected and operating under acceptable conditions. Patterns such as SPIFFE/SVIDs, signed workloads and verifiable credentials point in this direction because they tie identity to verifiable attributes rather than long-lived shared secrets.
Why passports are not enough
A human passport proves who I am. It does not give me permission to work in every country, access every building or perform every regulated activity. Those permissions require additional authorization.
Visas are scoped authority for a specific action or service. It may take the form of a transaction token, an On-Behalf-Of flow, a short-lived delegated authorization, or another tightly-constrained access mechanism. The implementation matters less than the principle: we need to make authority temporary, contextual, and revocable.
If I ask an agent to prepare a report from approved customer data, we have to tie its temporary access to my authority, my role, the task and the policy governing that data. If I leave the company, lose that role or no longer own the business process, the agent’s authority should disappear with me.
The same logic applies when an agent acts on behalf of a business process. A finance reconciliation agent may not have a single human user driving every action, but it still operates under business authority. Someone owns the process. Someone approved the policy. Someone was accountable for the outcome. The visa should reflect that chain of authority, not merely the fact that the agent authenticated successfully.
One agent may summarize a request, another retrieve data, another update a system of record and another trigger a downstream workflow. Each step may look harmless on its own. But the combined workflow can create a level of authority no single agent should possess permanently.
Every agent should have a passport. Every meaningful action should require a visa. And every visa needs a link to the verified human, service owner, or business process that authorized it.
Delegated authority requires verified identity
If agents are allowed to act because a person delegated authority, the organization needs strong assurance that the person delegating that authority has been verified, authorized and present at the right level of risk. In high-risk scenarios, that may require phishing-resistant authentication, biometric verification or another high-assurance method. We don’t want to add friction everywhere. We want to make sure the root of authority is trustworthy before autonomy begins.
Short TTLs, scoped credentials, revocation on user disablement, policy-based delegation, and clear audit trails are needed to prevent agent authority from becoming another version of the service account problem. The agent’s visa should live and die with the human or business context that authorized it.
When an agent accesses data, modifies a workflow or triggers a transaction, the organization should have the ability to answer more than “Which token was used?” It should know which agent acted, where it ran, what authority it had, who or what delegated that authority, what policy applied, and why the action was allowed.
That’s the difference between agent access logging and agent identity governance -- and it represents the next enterprise security challenge.
Mike Engle, chief strategy officer, 1Kosmos
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
