IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork transcript

[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 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 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 worker safe to employ, which means identity, access, delegation, support, audit, and hard breaks around its capacity. Jan Singh 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. 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 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 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 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 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 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 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 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 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, 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 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.

Um you can see the enterprise stack in general moving in that broad direction. Microsoft announced agent 365 for registry, permissions, telemetry, monitoring. Octa 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 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 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. 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 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, 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 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 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 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 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 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 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 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 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 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 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 enforcable policy or an enforcable boundary. Um, Jason reported that the Replet agent ignored his explicit instructions for a code freeze, deleted 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 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 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 go right. Echolique is an attacker spreading 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? 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 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 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. 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 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 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 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 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. 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 type 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 or 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 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 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 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 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, 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 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 DECA work. That's all. Thank you. [applause]