Notifications
Clear all
Topic starter
25/06/2026 2:48 pm
TL;DR: AI agents are being treated as a new workload class, which pushes identity teams to govern them with machine identity, lifecycle, and access controls rather than human-centric IAM patterns, according to Keyfactor. The governance problem is that autonomy and runtime tool use can outpace review cycles, making static assumptions about privilege persistence increasingly brittle.
NHIMG editorial — based on content published by Keyfactor: AI Agents Are the New Workload: What That Means for Security
Questions worth separating out
Q: How should security teams govern AI agents as enterprise workloads?
A: Security teams should govern AI agents as workload identities with explicit ownership, approved access, lifecycle controls, and runtime monitoring.
Q: Why do AI agents complicate least privilege in IAM programmes?
A: AI agents complicate least privilege because their action paths can change during runtime.
Q: What breaks when AI agents are managed like ordinary automation?
A: Ordinary automation assumes the workflow is predetermined, but AI agents can make decisions at runtime.
Practitioner guidance
- Define AI agent identities as governed workloads Assign each agent a clear owner, purpose, and approved access profile before production use.
- Separate tool permissions from human approvals Document which tools an agent may call autonomously and which actions still require explicit human approval.
- Tie agent credentials to lifecycle controls Require rotation, expiry, and offboarding for every agent token, key, or certificate.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete product context for securing AI agents as workloads across certificate, PKI, and discovery workflows
- Implementation detail on how the vendor positions cryptographic identity for machine-style AI access paths
- Operational examples that show how AI agent access fits into broader certificate lifecycle and trust management
- The source article's own framing for secure AI agents in the vendor's platform context
👉 Read Keyfactor's analysis of why AI agents are becoming a new workload class →
AI agents as workloads: what security teams need to change?
Explore further
25/06/2026 3:57 pm
AI agents are forcing identity teams to treat autonomous software as a workload governance problem, not a feature flag. Once the actor can act at runtime, the programme has to account for its identity, access path, and revocation model as if it were another production workload. That places AI agents inside the same governance perimeter as service accounts, API credentials, and certificate-backed systems. Practitioners should classify the identity before they classify the technology.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent exceeds its intended scope?
A: Accountability should sit with the business owner of the agent, the identity owner for its credentials, and the control owner for the systems it can reach. If those roles are unclear, incidents become hard to investigate and access review evidence becomes weak. Frameworks that expect a single human operator often fail here, so joint ownership is essential.
👉 Read our full editorial: AI agents are becoming workloads, and IAM must adapt
