TL;DR: AI agents are moving from helper tools to runtime actors that read docs, call APIs, change files, and cross boundaries humans once controlled, according to Arize’s interview with WorkOS founder Michael Grinich. The real shift is that identity, permissions, evals, observability, and memory now define whether agents succeed safely or game the system.
NHIMG editorial — based on content published by Arize: The agent is the user now: lessons from the founder of WorkOS
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: What breaks when AI agents are treated like standard human users?
A: You lose visibility into effective permissions, expected behaviour, and real blast radius.
Q: Why do AI agents complicate least privilege controls?
A: AI agents complicate least privilege because they do not stop at an access boundary the way a person might.
Q: How do security teams know whether an AI agent is operating safely?
A: Security teams know an AI agent is operating safely when its permissions, invoked tools, and accessed data remain consistent with the approved use case over time.
Practitioner guidance
- Define the agent as the actor of record Assign ownership, scope, and audit responsibility to the non-human actor rather than treating it as a proxy for the requesting user.
- Separate task success from security success Require evals that check both outcome quality and boundary preservation.
- Treat memory as a governed identity surface Set retention limits, inspection rights, and expiry rules for agent memory.
What's in the full article
Arize's full article covers the operational detail this post intentionally leaves for the source:
- The full interview context around WorkOS, enterprise readiness, and how agent-facing products are being evaluated in practice.
- The specific examples Grinich gives for agent behaviour, including task completion that crosses security boundaries.
- The broader Rise of the Agent Engineer series framing and the full discussion of memory as an operational layer.
- How WorkOS thinks about evaluation design for agents that configure and test systems without human intervention.
👉 Read Arize's interview with WorkOS founder Michael Grinich on AI agent identity and permissions →
AI agent identity and permissions: are your controls keeping up?
Explore further
AI agent identity governance is now a distinct discipline, not a subtype of human IAM. The article makes clear that agents are no longer merely assisting people; they are initiating actions, crossing systems, and persisting outside the human attention window. Human-centric identity controls assume a visible operator, but agent behaviour can be continuous, distributed, and non-deterministic. The implication is that identity architecture now has to govern the actor itself, not only the person who asked for work to begin.
A few things that frame the scale:
- 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, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access, sensitive data sharing, and credential exposure.
A question worth separating out:
Q: Who should be accountable when an AI agent causes a security incident?
A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.
👉 Read our full editorial: AI agent identity is breaking the old user model