Introduction
The prominence of Agentic AI and machine identity at a major security agenda reflects a practical concern: autonomous systems are becoming participants in business processes before governance models have caught up. An AI agent may be software, but its actions still require identity, authority and accountability. Treating those needs as an extension of ordinary application security leaves important gaps.
The problem
The problem is not simply that agents can be powerful. It is that their permissions are often assembled from service accounts, API keys and integrations owned by different teams. An agent can therefore inherit a broad and poorly understood authority model. When it acts unexpectedly, investigators may struggle to determine which identity made the decision, which tool executed it and whether a human approved the relevant step.
What security teams should examine
Security leaders need an identity architecture for agents
It should distinguish the human sponsor, the agent instance, the model or workflow, the tools it can use and the data boundaries that apply to each task.
Runtime controls should be policy-aware
A request to read a public record is different from a request to alter production data or release funds. The required assurance, approval and logging should change with the sensitivity of the action.
Identity telemetry must be usable by operations teams
Clear event trails linking agent decisions to credentials and downstream systems will be essential for incident response and auditability.
The conversation also belongs in procurement and design reviews
Vendors should explain how their agents authenticate, isolate tenants, rotate credentials, handle delegation and support rapid revocation when behaviour falls outside policy.