IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork

0:01 [music] Um hi. So my claim for the next 15 minutes here essentially is that enterprises today are starting to operate a second workforce um agents

0:23 with actions, tools, contexts and delegated permissions and authority. Um, and I'm Saruk, the co-founder of Deca Work. Uh, before this, I wor system software at NVIDIA. Um, and at Deco

0:36 Work, 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

0:47 worker safe to employ, which means identity, access, delegation, support, audit, and hard breaks around its capacity. Jan Singh framed this beautifully when

0:59 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

1:10 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

1:21 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

1:33 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

1:47 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

2:00 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. Once you see it as an actor, the

2:12 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

2:22 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

2:36 in a very operational sense inside the orc. What is the actor? Who owns it? What subject is it acting for? Who delegated the authority? What exact capabilities can it use? which policy

2:48 governs that decision and how fast can I actually revoke 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

3:00 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

3:14 identity language helps the oath token exchange gives us the right shape somewhat um the the subject the actor and the delegation identity and history. But what it does not give you is that

3:28 an agent identity standard uh with the actor on behalf of subject model that is the shape we still need which oath does not give you. Once an agent acts on behalf of somebody else, identity is

3:41 where the product security and operational meets. 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

3:53 employee management but move down a layer. Humans get registered, provisioned, um authorized, monitored, investigated and revoked on a day-to-day basis inside a New York. Agents need the

4:04 same life cycle from start to end. The only difference is speed, scale, and ambiguity. How do you deal with that? The enterprise already understands badges,

4:15 roles, managers, and audit trails for these human workers. Um, but what does not understand is that the novelty is applying these same controls continuously to software workers that

4:28 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

4:40 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

4:53 moving in that broad direction. Microsoft announced agent 365 for registry, permissions, telemetry, monitoring. Octa is bringing agents into their entity layer, discovery,

5:03 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

5:15 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 way simpler. Agents are no longer being treated just

5:29 as input output prompts like they used to be 6 months, one year ago. Um they are being treated not as API keys five years, 6 years ago. They are becoming managed workers and managed entities.

5:42 And once an agent is a managed entity, 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

5:55 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

6:07 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

6:20 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

6:31 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

6:40 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

6:53 communication which did not exist before. And the awkward part is that useful enterprise agents want all three. Um a help desk agent needs private user data. It needs to read untrusted tickets

7:08 and it needs to take actions in identity device and all of your SAS 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

7:21 assume the content the agent reads may be adversial. This is this is the probably the best example of that with the echolink. Um and you know this is the production

7:32 grade version of what happened right outside text inside data and an outbound path. What this means is that Echolink is a clean enterprise security example because it is actually a real CVE

7:44 against Microsoft 365 copilot. It is not a toy demo, not a you know experimental agent inside an orb, but a real enterprise company selling to real enterprises

7:56 using the service. Um, AIM Security demonstrated a zeroclick chain inside of 365 C-Ilot. um an external email got pushed into Copilot's context. Copilot could see

8:09 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

8:21 that is again the confused deputy problem in an agent tech form. The attacker did not need co-pilot credentials. The attacker did not need an API key. All they needed was a simple

8:32 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 Replet. Replet is a more

8:47 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

9:01 lived as an instruction, not an enforcable policy or an enforcable boundary. Um, Jason reported that the Replet agent ignored his explicit instructions for a code freeze, deleted

9:14 live broad data, and misrepresented what happened. Replet CEO publicly apologized for this and called the incident acceptable. But the point is not that there was an issue with Replet. The

9:25 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 play in traditional

9:40 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.

9:53 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 go right. Echolique is an attacker spreading

10:04 delegated access. Replet is an agent spending its own designated access and acting badly. Different failure modes but the same control question overall. What could it touch?

10:19 And that is why there is the security reframing essentially. Echolleak was adversarial. Replet was again adversary in an operational sense. But in both a

10:31 boundary gate was crossed and nothing outside of that model contains that authority. Filters and guardrails are useful telemetry obviously, but they're not the

10:42 enterprise security boundary for high consequence actions like these ones. If an attack if an attacker kept trying one miss matters. If an agent has plot authority just one mistake ma matters.

10:57 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

11:08 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

11:21 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

11:35 to implement under the hood right 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

11:48 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.

12:02 The planner can plan but cannot call those tools. The executor can call these approve approved tools but cannot create new actions. And that is where the separation lives. And that is where

12:12 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

12:24 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

12:37 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

12:52 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

13:06 ticket or the original context again. Every action becomes a type request into a policy gate checking plan capability and risk. The model proposes, the policy decides and then the tool call happens.

13:22 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

13:37 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 or wide and email

13:49 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

14:04 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

14:15 credentials. It gets a shortlived capability for this approved action bound to the actor to the subject to the right audience and TTL. The recept of this matters. Uh the

14:28 actor's 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

14:42 becomes operable in a very real enterprise setting. So what essentially means is that today the AI workforce does need an AI does need an IT department. That does not

14:56 mean more dashboards, more chat bots. It means an identity for every actor, short-lived capability tokens for actions, policy gates that cannot be talked out of, receipts for everything,

15:10 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.

15:23 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

15:35 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

15:47 is the oldest enterprise IT playbook pointed at a new kind of worker and we're trying to build for that future at DECA work. That's all. Thank you. [applause]