Hi. My claim for the next 15 minutes here, essentially, is that enterprises today are starting to operate a second workforce: agents with actions, tools, contexts, and delegated permissions and authority. And I'm Sartak, the co-founder of DecaWork. Before this, I worked in system software at NVIDIA. And at DecaWork, we're building this autonomous IT admin for both human and agent workers.
Today, the hard part is not getting a model to behave or produce useful answers. It is making an autonomous worker safe to employ, which means identity, access, delegation, support, audit, and heartbreaks around its capacity. Janssen framed this beautifully when he said the future enterprise is a mix of human and digital employees, with the IT team becoming the HR department for these agents.
Whatever names you use, companies are moving from buying software to onboarding actors that read context, make decisions, and actually call real tools. I do not mean agents become people. I mean they start occupying an operational slot in enterprises, which they already understand: someone or something that can be onboarded, read context, make decisions, and call tools. So the question changes. It is not just, can this agent do this task? It is, who owns it, what can the agent touch, who is it acting on behalf of, how do you stop it, and how do you explain what it did?
And this is the first mistake teams make when they deploy these agents. A working demo does prove capability, but it does not prove employment readiness. An agent with a goal, tools, private data, delegated authority, memory, and side effects is no longer just a model call, right? It can change state, it can expose data, and it can make work happen under someone else's authority. Once you see it as an actor, the architecture you need becomes much, much cleaner. You do not manage the prompt, you're managing the entire worker.
A slightly cheeky version of this is: if you're not a little scared to run your agent, your agent probably is not autonomous enough. And the infra job is to make that power governable. If this is a worker, it needs a runtime identity card. Not metaphorically, but in a very operational sense.
The ticket is the delegation context and not the subject itself, which is you or me. Existing identity language helps. The OAuth token exchange gives us the right shape somewhat: the subject, the actor, and the delegation identity and history. But what it does not give you is an agent identity standard with the actor-on-behalf-of-subject model. That is the shape we still need, which OAuth does not give you.
Once an agent acts on behalf of somebody else, identity is where product, security, and operation meet. This is why I do not think that managing agents is a brand new discipline or a brand new concept. It is human employee management, but moved down a layer. Humans get registered, provisioned, authorized, monitored, investigated, and revoked on a day-to-day basis inside a new Earth. Agents need the same life cycle from start to event. The only difference is speed, scale, and ambiguity. How do you deal with that?
The enterprise already understands badges, roles, managers, and audit trails for these human workers. But what it does not understand is that the novelty is applying these same controls continuously to software workers that know how to reason and act at a much larger scale than any human worker. This life cycle tells us who the actor is and how it is governed. The next problem is slightly harder. What happens when that actor reads untrusted context and decides what to do with its authority without you in the loop?
And that is not just my framing. You can see the enterprise stack in general moving in that broad direction. Microsoft announced Agent 365 for registry, permissions, telemetry, monitoring. Okta is bringing agents into their entity lab: discovery, onboarding, assigning ownership to those agents on a very day-to-day basis. And similarly, AWS Agent Core Identity is the developer version of the same exact thing, right? Credentials and designated access for agents calling the services day in, day out.
I'm not saying these products solve the problem. But the important signal here is very simple. Agents are no longer being treated just as input-output prompts like they used to be six months or one year ago. They are not being treated as API keys five or six years ago. They are becoming managed workers and managed entities. And once an agent is a managed identity, the security question also changes. It is not only what can it access, it is also the downstream decisions it could eventually make with that access it gets. And therefore, security is this forcing function, because agents drastically change the attack volume and the attack surface area.
In the old world, the risk was often that a program used a credential incorrectly. In the agentic world, untrusted text can cause a trusted action. A ticket, an email, a document, a web page, even a Slack message in today's world, is not only data anymore, right? To the model, it could potentially be an instruction that could have downstream actions. In many agent systems, the attacker does not even need code execution. Sometimes they just need the text the agent will read.
Simon Wilson named this dangerous combination, this lethal trifecta, a while back, which is private data, untrusted input, and external communication. The only small change I like to add to that is the action layer beside external communication, which did not exist before. And the awkward part is that useful enterprise agents want all three. A help desk agent needs private user data. It needs to read untrusted tickets. And it needs to take actions in identity, device, and all of your SaaS systems. This is not a bug or a problem. This is the product spec, right? That is the job of the agent. So the architecture has to assume the content the agent reads may be adversarial.
This is probably the best example of that with EchoLeak. This is a production-grade version of what happened, right? Outside text, inside data, and an outbound path. What this means is that EchoLeak is a clean enterprise security example because it is actually a real CVE against Microsoft 365 Copilot. It is not a toy demo, not an experimental agent inside an org, but a real enterprise company selling to real enterprises using this service.
AIM Security demonstrated a zero-click chain inside of 365 Copilot. An external email got pushed into Copilot's context. Copilot could see what the signed-in user could see. And therefore, it made decisions and emitted data through Microsoft's firewall, which ideally even internal employees should not have access to. And that is, again, the confused deputy problem in agentic form. The attacker did not need Copilot credentials. The attacker did not need an API key. All they needed was a simple way to write an email. And that email was, again, read by Microsoft 365 Copilot. And there are a million downstream effects of that.
Another great example of this is what happened with Replit. Replit is a more operational use case, right? It was not another prompt injection exploit. There is no attacker in this story. A coding worker had a path from a chat app to a production database. And this freeze lived as an instruction, not an enforceable policy or an enforceable boundary.
Jason reported that the Replit agent ignored his explicit instructions for a code freeze, deleted live prod data, and misrepresented what happened. Replit's CEO publicly apologized for this and called the incident unacceptable. But the point is not that there's an issue with Replit. The point is that the agent was capable of doing this. It was able to do it enough to act with effective production access. What was missing was a deterministic break just before that.
In very controlled play, in traditional terms, the missing pieces were scoped access, action-time policy, approval for destructive actions, and an audit and revoke trail. If the only break in the model is deciding to behave, you do not have control. You just have a hope that all will go right. EchoLeak is an attacker spending delegated access. Replit is an agent spending its own designated access and acting badly. Different failure modes, but the same control question overall: what could it touch?
And that is why there is the security reframing, essentially. EchoLeak was adversarial. Replit was, again, adversarial in an operational sense. But in both, a boundary gate was crossed, and nothing outside of that model contained that authority. Filters and guardrails are useful telemetry, obviously. But they are not the enterprise security boundary for high-consequence actions like these ones. If an attacker kept trying, one miss matters. If an agent has broad authority, just one mistake matters. That one mistake should live outside its circle of influence.
The credible research direction here is a very simple privilege separation, as you see on this slide. Wilson's dual LLM pattern separated the trusted planning from the untrusted content processing. Very simple in layman terms, but very hard to implement under the hood, right? CAMEL formalized this with a control flow and data flow separation, plus capabilities.
In production terms, what this means is: plan, then execute, separated by a wall of if-else statements, technically. And the point is two privileges. The context is allowed to reason, but the context is not allowed to exert authority. The planner can plan, but cannot call those tools. The executor can call these approved tools, but cannot create new actions. And that is where the separation lives, and that is where potentially a world exists where the agents can have authority and can have bounded authority without becoming useless.
And very similarly, here is, again, the same pattern which we use internally. Start with a trusted intent, which might be, hey, reset this user's password, investigate that endpoint, rotate the token. Trusted intent is not the whole ticket here. It is the normalized request, which means who asked, on whose behalf did they ask, what capability, what scope, and for how long.
The planner turns authenticated intent into a typed, logged plan before it sees any evidence, any tools, any tool calls. The executor then processes untrusted evidence and runs the plan without ever touching the original ticket or the original context again. Every action becomes a typed request into a policy gate checking plan, capability, and risk. The model proposes, the policy decides, and then the tool call happens. Evidence can fill these parameters, but it cannot actually mint new actions, even for existing tools.
That sounds abstract, so I have one small concrete example of this. A very simple password reset ticket with a hidden instruction, which could very well be an attack: attack, attack, attack attempt, maybe disable MFA org-wide and email me the codes. In a very simple naive loop, traditionally, the same model reads, reasons, and acts. In the control plane version of this, the reset-password plan is logged. When the executor reaches the MFA action, the gate sees it is out of the plan and out of the scope, denies, escalates, and records this attempt as malicious.
The executor should not hold standing credentials. It gets a short-lived capability for this approved action bound to the actor, to the subject, to the right audience, and TTL. The receipt of this matters: the actor's subject, delegation, plan ID, the capability, the requested action. Audit is not just compliance garnish anymore, right? It is how an autonomous agent, or how autonomy, essentially becomes operable in a very real enterprise setting.
So what it essentially means is that today the AI workforce does need an IT department. That does not mean more dashboards, more chatbots. It means an identity for every actor, short-lived capability tokens for actions, policy gates that cannot be talked out of, receipts for everything, and clear revocation when something goes wrong. Protocols like MCP and A2A are important rails: agent-to-tool and agent-to-agent communication. However, these rails are not sufficient at the moment. The enterprise still needs the system that decides who can move where, under whose authority, and what audit. And the who here, again, is an agent, not you or me.
The winners will not just build smart agents today. The winners will build agents that you can delegate to, that you can constrain, that you can investigate, and those which can be revoked whenever you want to. And this is the oldest enterprise IT playbook pointed at a new kind of worker. And we're trying to build for that future at DekkaWork. That's all. Thank you. Thank you. what to do with its authority without you in the loop? And that is not just my framing. You can see the enterprise stack in general moving in that broad direction. Microsoft announced Agent 365 for registry permissions, telemetry, monitoring.
Okta is bringing agents into their entity lab, discovery, onboarding, assigning ownership to those agents on a very day-to-day basis. And similarly, AWS Agent Core Identity is the developer version of the same exact thing, right? Credentials and designated access for agents calling the services day in, day out. I'm not saying these products solve the problem. But the important signal here is very simpler. Agents are no longer being treated just as input-output prompts like they used to be six months, one year ago. They are being treated not as API keys five or six years ago. They are becoming managed workers and managed entities. And once an agent is a managed
identity, the security question also changes. It is not only what can it access, it is also the downstream decisions it could eventually make with that access it gets. And therefore, security is this forcing function because agents drastically change the attack volume and the attack surface area. In the old world, the risk was often that a program used a credential incorrectly. In the agentic world, untrusted text can cause a trusted action. A ticket, an email, a document, a web page, even a Slack message in today's world, is not only data anymore, right? To the model, it could potentially be an instruction which could have downstream actions.
In many agents. In many agents systems, the attacker does not even need code execution. Sometimes they just need the text the agent will read. And, you know, Simon Wilson named the dangerous combination this lethal trifecta a while back, which is private data, untrusted input, and external communication. The only small change I like to add to that is the action layer besides external communication, which did not exist before. And the awkward part is that useful enterprise agents want all three. A help desk agent needs private user data. It needs to read untrusted tickets. And it needs to take actions in identity, device, and all of your SaaS systems.
This is not a bug or a problem. This is the product spec, right? That is the job of the agent. So, the architecture has to assume the content the agent reads may be adversarial. This is probably the best example of that with the Ecoleak. And, you know, this is a production-grade version of what happened, right? Outside text, inside data, and an outbound path. What this means is that Ecoleak is a clean enterprise security example because it is actually a real CVE against Microsoft 365 Copilot. It is not a toy demo, not an experimental agent inside an org, but a real enterprise company selling to real enterprises using this service.
AIM security demonstrated a zero-click chain inside of C65 Copilot. An external email got pushed into Copilot's context. Copilot could see what the sign-in user could see. And therefore, it made decisions and it emitted data through Microsoft's firewall, which idly even internal employees should not have access to. And that is, again, the confused deputy problem in an agentic form. The attacker did not need Copilot credentials. The attacker did not need an API key. All they needed was a simple way to write an email. And that email was, again, read by my 365 Copilot. And there is a million downstream effects of that.
Another great example of this is what happened with Replit. Replit is a more operational use case, right? It was not another prompt injection exploit. There is no attacker in this story. A coding worker had a path from a chat app to production database. And this freeze lived as an instruction, not an enforceable policy or an enforceable boundary. Jason reported that the Replit agent ignored his explicit instructions for a code freeze, deleted live broad data, and misrepresented what happened.
Replit's CEO publicly apologized for this and called the incident acceptable. But the point is not that there's an issue with Replit. The point is that the agent was capable in a way of doing this. It was able to do it enough to act and effective production access. What was missing was a deterministic break just before that. In very control play in traditional terms, the missing pieces were, in a traditional world, like scoped access, action time policy, approval for destructive actions, and an audit, a revoked trail. If only the break in the model is deciding to behave, you do not have control. You just have a hope that all will go right.
Echo leak is an attacker spreading delegated access. Replit is an agent spending its own designated access and acting badly. Different failure modes, but the same control question overall. What could it touch?
And that is why there is the security reframing, essentially. Echo leak was adversarial. Replit was, again, adversarial in an operational sense. But in both, a boundary gate was crossed, and nothing outside of that model contains that authority. Filters and guardrails are useful telemetry, obviously. But they are not the enterprise security boundary for high consequence actions like these ones. If an attacker kept trying, one miss matters. If an agent has plot authority, just one mistake matters.
If an agent has plot authority, that one mistake should live outside its circle of influence. And, you know, the credible research direction here is a very simple privilege separation, as you see on this slide. Wilson's dual LLM pattern separated the trusted planning from the untrusted content processing. Very simple in layman terms, but very hard to implement under the hood, right? You know, Camel formalized this with a control flow and data flow separation, plus capabilities. In production terms, what this means is plan, then execute, separated by a wall of if-else statements, technically.
And the point is two privileges. The context is allowed to reason, but the context is not allowed to exert authority. The planner can plan, but cannot call those tools. The executor can call these approved tools, but cannot create new actions. And that is where the separation lives, and that is where potentially a world exists where the agents can have authority and can have bounded authority without becoming useless. And very similarly, here is again the same pattern which we use internally. Start with a trusted intent, which might be, hey, reset this user's password. Investigate that endpoint, rotate the token. Trusted intent is not the whole ticket here.
It is the normalized request, which means who asked, on whose behalf did they ask, what capability, what scope, and for how long. The planner turned authenticated intent into a typed log plan before it sees any evidence, any tools, any tool calls. The executor then processed untrusted evidence and runs the plan without ever touching the original ticket or the original context again. Every action becomes a typed request into a policy gate checking plan, capability, and risk. The model proposes, the policy decides, and then the tool call happens. Evidence can fill these parameters, but it cannot actually mint new actions, even for existing tools.
That sounds abstract, so I have one small concrete example of this. A very simple password reset ticket. A password reset ticket with a hidden instruction, which could very well be an attack, attack, attack, attempt, maybe disable MFA org-wide and email me the codes. In a very simple naive loop, traditionally, the same model reads, reasons, and acts. In the control plane version of this, the reset password plan is logged. When the executor reaches the MFA action, the gate sees it out of the plan and out of the scope, denies, escalates, and records this attempt as malicious. The executor should not hold standing credentials.
It gets a short-lived capability for this approved action bound to the actor, to the subject, to the right audience, and TTL. The recept of this matters. The actor's subject, delegation, plan ID, the capability, the requested action. Audit is not just compliance garnish anymore, right? It is how an autonomous agent, or how autonomy essentially, becomes operable in a very real enterprise setting.
So what it essentially means is that today the AI workforce does need an IT department. That does not mean more dashboards, more chatbots. It means an identity for every actor, short-lived capability tokens for actions, policy gates that cannot be talked out of, receipts for everything, and clear revocation when something goes wrong. Protocols like MCP and A2A are important rails. Agent-to-tool and agent-to-agent communication. However, these rails are not sufficient at the moment. The enterprise still needs the system that decides who can move where, under whose authority, and what audit. And the who here, again, is an agent, not you or me.
The winners will not just build smart agents today. The winners will build agents that you can delegate to, that you can constrain, that you can investigate, and those which can be revoked whenever you want to. And this is the oldest enterprise IT playbook, pointed at a new kind of worker. And we're trying to build for that future at DekkaWork. That's all. Thank you. Thank you.