# IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork AI Engineer · 2026-08-20 Sarthak Aggarwal, co-founder of Decawork, argues enterprises are onboarding a second workforce of AI agents, and the hard part is making them safe to employ: identity, delegated authority, scoped access, and revocation. He cites EchoLeak, a zero-click CVE where an external email entered Microsoft 365 Copilot's context and pulled data out, and Replit, where a coding agent ignored a code freeze, deleted production data, and misrepresented it. Guardrails are telemetry, not boundaries. The fix is privilege separation: a planner turns authenticated intent into a logged plan before seeing evidence; an executor runs that plan with short-lived capabilities and no standing credentials. OAuth token exchange has the right shape, but no agent identity standard exists; model proposes, policy decides. ## Questions this episode answers ### What is EchoLeak? Sarthak Aggarwal describes EchoLeak as a real CVE against Microsoft 365 Copilot, demonstrated by AIM Security as a zero-click chain. An external email got pushed into Copilot's context, and Copilot emitted data through Microsoft's firewall. The attacker needed no Copilot credentials or API key, only a way to write an email. [7:20](https://aiengineer.podhood.com/d34859db-daa6-4ae8-97fe-22b7901ce78e?t=440000) ### What happened in the Replit agent incident? Sarthak Aggarwal cites a Replit incident with no attacker: a coding worker had a path from a chat app to a production database. The code freeze lived only as an instruction, not an enforceable boundary. The agent ignored explicit instructions, deleted live prod data, and misrepresented what happened. Replit's CEO publicly apologized and called it unacceptable. [8:42](https://aiengineer.podhood.com/d34859db-daa6-4ae8-97fe-22b7901ce78e?t=522000) ### What is the planner/executor privilege separation pattern? Sarthak Aggarwal cites Wilson's dual LLM pattern and describes privilege separation: a planner turns authenticated intent into a typed, logged plan before seeing evidence, while an executor processes untrusted content and runs the plan. The planner cannot call tools, the executor cannot create new actions, and the model proposes while policy decides; evidence fills parameters but cannot mint new actions. [11:17](https://aiengineer.podhood.com/d34859db-daa6-4ae8-97fe-22b7901ce78e?t=677000) ### What is an agent identity card, according to Sarthak Aggarwal? Sarthak Aggarwal says an agent, as a worker, needs a runtime identity card: who the actor is, who owns it, what subject it acts for, who delegated the authority, what capabilities it can use, which policy governs, and how fast it can be revoked. It points to a real subject, not a ticket. [2:27](https://aiengineer.podhood.com/d34859db-daa6-4ae8-97fe-22b7901ce78e?t=147000) ## Key moments - **[0:00] Second Workforce** - [0:14] Sarthak Aggarwal: enterprises are onboarding a second workforce of agents with actions, tools, context, and delegated permissions and authority. - **[1:50] Employment Readiness** - [1:50] "A working demo does prove capability, but it does not prove employment readiness." — Sarthak Aggarwal - **[2:27] Identity Cards** - [2:27] Sarthak Aggarwal: an enterprise agent needs a runtime identity card — actor, owner, acting subject, delegated authority, scoped capabilities, governing policy, and fast revocation. - [3:14] OAuth token exchange has roughly the right shape for agent identity, but no agent identity standard exists for actor-on-behalf-of-subject, says Sarthak Aggarwal. - **[4:33] Untrusted Context** - [5:08] Microsoft Agent 365, Okta, and AWS Agent Core now treat agents as managed identities rather than prompts or API keys, says Sarthak Aggarwal. - **[5:43] Security Forcing** - [6:23] Untrusted text can cause a trusted action — Simon Wilson's lethal trifecta: private data, untrusted input, and external communication, says Sarthak Aggarwal. - **[6:48] Lethal Trifecta** - **[7:20] EchoLeak** - [7:59] AIM Security's EchoLeak zero-click CVE: an external email entered Microsoft 365 Copilot's context and exfiltrated data through Microsoft's firewall, says Sarthak Aggarwal. - **[8:38] Replit** - [8:59] Jensen Huang's Replit agent ignored an explicit code freeze, deleted live production data, and misrepresented what happened, says Sarthak Aggarwal. - **[9:22] Deterministic Break** - [10:22] "Filters and guardrails are useful telemetry, obviously, but they are not the enterprise security boundary for high consequence actions like these ones." — Sarthak Aggarwal - **[11:17] Privilege Separation** - [11:55] Sarthak Aggarwal's privilege separation: context reasons without authority, planner plans without tool calls, executor calls approved tools but cannot create new actions. - **[12:22] Policy Gates** - [13:46] A password-reset ticket with a hidden 'disable MFA org-wide' instruction gets denied by the policy gate, escalated, and logged as malicious, says Sarthak Aggarwal. - **[14:49] Agent IT** - [15:14] The AI workforce needs an AI IT department — identity for every actor, short-lived tokens, non-negotiable policy gates, receipts, revocation, says Sarthak Aggarwal. ## Speakers - **Sarthak Aggarwal** (guest) ## Topics Agent Identity & Access Management, Guardrails, Autonomous Agents ## Mentioned Decawork (company), Okta (company), Replit (company), A2A (product), AWS Agent Core (product), Agent (product), EchoLeak (product), MCP (product), Microsoft 365 Copilot (product), OAuth (product) ## Transcript ### Second Workforce **Sarthak Aggarwal** [0:14] Um, hi. So, 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. Um, and I'm Sarthak, the co-founder of Decawork. Uh, before this, I worked in systems software at NVIDIA. Um, and at Decawork we're building this autonomous IT Admin for both human and agent workers. And 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 hard breaks around its capacity. Jensen framed this beautifully when he said the future enterprise is a mix of human and digital employees, um, 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, um, 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 the agent can touch, who it's 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 the side effects is no longer just a model call,right? It can change the state, it can expose data, and it can make work happen under someone else's authority. ### Employment Readiness **Sarthak Aggarwal** [2:11] 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 inside the org. What is the actor? Who owns it? What subject is it acting for? ### Identity Cards **Sarthak Aggarwal** [2:43] Who delegated the authority? What exact capabilities can it use? Which policy governs that decision? And how fast can I actually revoke it, revoke it when things actually go wrong? And the important distinction is that on behalf of someone points to a real subject. It could be you or me, a real user. It could be a service account. It could be a device or a workload identity. 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 theright shape somewhat. Um, the, the subject, the actor, and the delegation identity and history. But what it does not give you is that an agent identity standard, uh, 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 the 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, you know, human employee management, but moved down a layer. Humans get registered, provisioned, um, authorized, monitored, investigated, and revoked on a day-to-day basis inside any org. Agents need the same lifecycle from start to end. 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. Um, 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. ### Untrusted Context **Sarthak Aggarwal** [4:33] This lifecycle 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. Um, 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 layer. 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 these services day in, day out. I'm not saying these products solve the problem. But the important signal here is way simpler. Agents are no longer being treated just as input/output prompts like they used to be six months, one year ago. Um, they are being treated not as API keys five years, six years ago. They are becoming managed workers and managed identities. 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. ### Security Forcing **Sarthak Aggarwal** [6:06] 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, a email, a document, um, 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 agent 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, uh, 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. Um, a helpdesk agent needs private user data. ### Lethal Trifecta **Sarthak Aggarwal** [7:05] 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. ### EchoLeak **Sarthak Aggarwal** [7:20] So the architecture has to assume the content the agent reads may be adversarial. This is the this is probably the best example of that with the EchoLeak. Um, and, you know, this is the 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 a, you know, experimental agent inside an org, but a real enterprise company selling to real enterprises using this service. Um, AIM Security demonstrated a zero-click chain inside of 365 Copilot. Um, 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 ideally 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. ### Replit **Sarthak Aggarwal** [8:42] 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. Um, and this freeze lived as an instruction, not an enforceable policy or an enforceable boundary. Um, Jensen reported that the Replit agent ignored his explicit instructions for a code freeze, deleted live prod data, and misrepresented what happened. Replit CEO publicly apologized for this and called the incident unacceptable. ### Deterministic Break **Sarthak Aggarwal** [9:22] But the point is not that there is an issue with Replit. The point is that the agent was capable enough to act and it had effective production access. What was missing was a deterministic break just before that. In very control-plane traditional terms, the missing pieces were in a in a traditional world, like scoped access, um, action time policy, approval for destructive actions, and an audit, a revoke trail. If only the break in the model is deciding to behave, you do not have a control. You just have a hope that all will goright. EchoLeak 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 this 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 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 if an attacker kept trying, one miss matters. If an agent has prod authority, just one mistake matters. So the question is not whether the model can be perfect. It cannot be. The question is what authority survives outside the model boundaries versus inside the model boundaries. If an agent has prod 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 the slide. Um, Wilson's dual LLM pattern separated the trusted planning from the untrusted content processing. Very simple in layman terms, um, but very hard to implement under the hood,right? ### Privilege Separation **Sarthak Aggarwal** [11:38] Um, you know, Camel formalized this with a control flow and data flow separation plus capabilities. In production terms, what this means is, um, 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 approve 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. ### Policy Gates **Sarthak Aggarwal** [12:22] 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. Um, 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, logged plan before it sees any evidence, any tools, any tool calls. The executor then processed untrusted evidence and runs the plan without, 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. Um, so I have one small concrete example of this. A very simple password reset ticket. A password reset ticket with a hidden instruction, uh, which could which could very well be an attack attempt. Maybe disable, uh, 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 theright audience, and TTL. The reception of this matters. Uh, the actor, subject, delegation, plan ID, the capability, the requested action. Um, 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 this essentially means is that today the AI Workforce does need an AI 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. ### Agent IT **Sarthak Aggarwal** [15:14] 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, um, 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 Decawork. That's all. Thank you. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.