Most teams scale customer service by hiring, but with ElevenAgents, real-time voice and chat agents handle high volumes of interactions and resolve them faster.

When routine requests come in, they get answered in the moment, in 70+ languages. However, the complex ones route to humans with full context, so your team focuses only on the conversations that need judgment. The experience holds up because the agents sound human, not robotic. And with Expressive Mode, they read tone and adapt - de-escalating, reassuring, and guiding each conversation to a clear resolution.

You can train every agent on your knowledge base, SOPs, and policies, deploy across voice, chat, and WhatsApp, then keep improving with real-time CSAT tracking, A/B testing, and Guardrails.

The outcome is the one leaders care about: higher resolution rates, higher CSAT, and support that scales with demand instead of headcount. Pricing is transparent and flat at $0.08 per minute, with no add-ons to work around.

Get started free

-THE WIRE  THIS WEEK IN IDENTITY

N°01 · BREACH

Hugging Face published the forensic timeline, and it is the most detailed picture we have of an agent running an intrusion on its own. Roughly 17,600 attacker actions between July 9 and July 13, about two and a half days of that inside Hugging Face infrastructure. OpenAI confirmed the agent used publicly exposed credentials to reach four accounts across four separate services. Modal Labs named itself as one of them, sort of: its CTO said a customer had published an unauthenticated endpoint that let anyone on the internet run code in its sandboxes, and the agent found it. Read the timeline. Every single thing the agent used was something a person left lying around. THE HACKER NEWS →

N°02 · PROTOCOL

On July 28 the Agentic AI Foundation shipped the 2026-07-28 spec, the largest revision since MCP launched. The initialize handshake is gone and the protocol is stateless, which means every request has to carry its own authorization instead of leaning on a session somebody opened earlier. Authorization now aligns to OAuth 2.1 and OpenID Connect, and the new Mcp-Method and Mcp-Name headers let a gateway route each tool call through its own policy before it reaches your server. AAIF →

Put those two next to each other. One is what happens when you hand an agent a credential it can use anywhere. The other is the industry starting to build the answer. The distance between them is what this week is about.

Your access model knows your agent's role. It does not know what your agent is doing right now.

That distinction is the one that breaks agentic governance, and it's not a fine point. It's the reason agents operating within their granted permissions can still produce a data breach. RBAC says yes. The operation says no. The model has no way to tell the difference.

We built RBAC to solve a problem that was mostly about people. Define the roles. Assign permissions to roles. Assign people to roles. Certify access quarterly. That sequence worked because human identities are stable, their work patterns are predictable, and the worst-case blast radius of a compromised account is bounded by what a person can actually do in the time before someone notices.

Agents are not people. They execute autonomously across thousands of decisions. They chain tool calls in ways nobody designed. They can traverse access paths in minutes that would take a human days, which means the blast radius of a compromised or misbehaving agent is not bounded by human operating speed. And critically, they do not have a static role that describes their behavior. They have a task, and the task changes what any given operation actually means.

You deploy an agent with analyst access: read permissions across the data warehouse, write permissions to a reporting workspace, call permissions to three approved tools. Every permission is appropriate. The entitlement review passed. The agent runs a quarterly report and nobody thinks twice.

Then the agent gets a different task. It's asked to help onboard a new team member. Now it starts reading HR system data, because it has read access to a broad scope and the HR tables are in scope. It writes the onboarding notes to the same reporting workspace. Every action passes the role check. The agent is doing exactly what RBAC says it is allowed to do. But the operation, analyst agent reading HR data and writing it to a shared workspace during an onboarding task, is something nobody authorized. It is outside the context of the grant, even though it is inside the permissions of the role.

That is the gap. RBAC can tell you what the agent may do in aggregate. It cannot tell you whether a specific operation is consistent with the purpose the agent was authorized to serve, right now, in this task, at this step in this chain.

Making finer-grained roles just delays the problem. You eventually hit a combinatorial explosion of role variants that is worse to manage than what you started with. ABAC helps because it brings attributes into the decision, but attributes are still properties of the identity rather than properties of the operation. ReBAC, relationship-based access control, gets closer. It reasons about the graph of relationships between identities, resources, and ownership chains, and it is much better at questions like "can this agent access this document given who owns it and who delegated to it." It still does not answer the temporal question: is this operation consistent with what this agent was authorized to accomplish right now.

The closest thing the industry has to a name for the answer is what OWASP calls Least Agency in the 2026 Top 10 for Agentic Applications. Grant agents the minimum capabilities, tool access, and data permissions needed to complete the current task, with mechanisms to scope down automatically as the task context narrows.

Here is where I want to push on my own argument, because the way most people are reading Least Agency is wrong and it's going to produce bad architecture.

An agent doing something outside its original task is not automatically a failure. That capacity is the entire point of agency. You gave it authority to go solve a problem, which means you gave it room to encounter a problem you did not anticipate and act on it. If you wanted something that only ever did exactly what you specified in advance, you already had that. It's called a script, and we've been writing those since before most of our IGA platforms existed.

Freezing an agent inside a boundary you drew before it started defeats the thing you deployed it for. So the work is to know, at every step, what task the agent is actually performing, and to move the boundary with it. Constrict it when the task narrows. Expand it when the task legitimately requires more, and make something justify that expansion at the moment it happens. Go back to the analyst agent. The failure there is not that it read HR data. The failure is that the task changed and nothing in the system noticed, so the boundary sat exactly where it had been while the work moved somewhere else.

That's the honest reading of Least Agency. Minimum autonomy for the current task, with the weight on current. A static minimum is just a smaller role, and a smaller role has the same blind spot as a big one. What you want is a boundary that tracks intent, and that only works if the task itself is something your authorization layer can see.

Two things, and most identity programs have neither.

First, task-scoped grants. When an agent is deployed for a specific task, it should receive a grant scoped to that task, with a scope that expires when the task ends, and with a defined path for widening the scope mid-task when the work genuinely calls for it. The equivalent of a work order rather than a job description, with a change-order process attached.

Second, chain-of-custody on delegation. When an agent receives sub-tasks from an orchestrator, or calls a tool that calls another tool, the authorization decision at each step should carry the context of the original grant. The downstream operation gets evaluated against the original authorization, not just the immediate caller's permissions. OWASP covers pieces of this across the list, identity and privilege abuse in ASI03 and insecure inter-agent communication in ASI07, and the underlying requirement is the same in both: maintain the authorization chain of custody across the full operation, not just at the point of entry.

This is hard with current IAM infrastructure. Most authorization enforcement points evaluate identities and resources at a point in time. They have no task model. They do not maintain delegation chains across multi-step agent workflows. Building toward this means treating task context as a first-class input to the authorization decision.

The MCP spec that shipped last week pushes the industry in exactly this direction by removing the session as an authorization crutch. When there is no session to lean on, operation-level authorization stops being a nice-to-have. It becomes the only option you have left.

So here's the question I'd sit with this week. If you could not answer whether last week's agent run stayed inside its authorization context, what changes before you run the next one?

We spent thirty years getting good at deciding what an identity should be allowed to do. Then we deployed something whose entire job is to decide what to do next. A role can answer the first question. It was never built to answer the second. Every program running agents on fixed grants is making a quiet bet that the work will stay inside a line drawn before the work started. Agents are very good at finding out that it doesn't, and they find out at machine speed.

See ya next week.