Topic starter
17/08/2026 4:39 pm
TL;DR: C1.ai shows agentic AI identity is diverging into company, employee, and agent-to-agent models, each with different authorization and audit problems because agents act more dynamically than static service accounts. Traditional IAM assumptions break when access becomes task-scoped, cross-system, and harder to certify.
Editorial analysis by NHI Mgmt Group, based on content published by C1.ai: “The Divergent AI Landscape: Making Sense of Agentic AI”.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do agent-to-agent workflows create more identity risk than single-agent automations?
A: Because each agent handoff introduces another authorisation decision, another trust boundary, and another place where accountability can blur.
Q: What breaks when AI agents are given broad inherited permissions?
A: Broad inherited permissions break the assumption that access is tied to a narrow business need.
Practitioner guidance
- Classify every agent by operating model Separate embedded company agents, employee-facing agents, and agent-to-agent workflows before assigning access so each one receives a distinct governance pattern.
- Scope embedded agents to app-local duties Limit company agents to the business function they support and avoid granting broad platform-wide privileges that exceed their actual workflow.
- Model delegated permissions for employee agents Define what an agent can do on behalf of a user as a separate access object instead of copying the human user's full entitlement set.
Bottom line: Agentic AI identity diverges because company, employee, and peer-agent models need different authorisation and audit controls.
What's in the full article
C1.ai's full blog covers the operational distinctions this post intentionally leaves at the governance level:
- Examples of company agents embedded inside specific SaaS applications and how their workflows differ from human-driven automation
- The article's detailed framing of employee agent permission inheritance and why sub-user access is difficult to express in current IAM models
- The peer-to-peer agent scenario showing how cross-system validation and execution complicate authorisation and accountability
- The broader discussion of why traditional static identity assumptions do not map cleanly to ephemeral agent behaviour
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:44 pm
Agentic AI identity is not one control problem, but three. Company agents, employee agents, and agent-to-agent systems each break a different part of the identity model, so treating them as a single category guarantees mis-scoped access and poor auditability. The practitioner error is assuming that all agents can be governed through one blanket policy set. Teams need separate governance logic for embedded, delegated, and peer-to-peer agent behaviour.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations manage company agents and employee agents with the same IAM policies?
A: No. Company agents are typically app-bound and can often be governed like constrained workload identities, while employee agents cross tools and inherit parts of a user's permissions. A single policy model usually overstates one and understates the other. Separate governance keeps application autonomy, user delegation, and audit expectations aligned.
👉 Read our full editorial: Agentic AI identity diverges across company, employee, and peer agents