IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork

Talk transcript

1. 0:00

   [upbeat music] Um, hi. So my claim for the next fifteen minutes here essentially is that enterprises today are starting to operate a second workforce, um, agents with actions, tools,

2. 0:25

   contexts, and delegated permissions and authority. Um, and I'm Sarthak, the co-founder of Decawork. Uh, before this, I worked in system software at NVIDIA. Um, and at Decawork, we're building this autonomous IT admin for both human and agent workers.

3. 0:41

   And today, the hard part is not getting a model to behave or produce useful answers. It is making autonomous worker safe to employ, which means identity, access, delegation, support, audit, and hard brakes around its capacity.

4. 0:58

   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.

5. 1:08

   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.

6. 1:18

   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.

7. 1:32

   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?

8. 1:42

   And how do you explain what it did?

9. 1:45

   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?

10. 2:03

    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.

11. 2:15

    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.

12. 2:26

    And the infra job is to make that power governable.

13. 2:31

    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?

14. 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?

15. 2:53

    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.

16. 3:03

    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 the right shape somewhat, um, the, the subject, the actor, and the delegation identity and history.

17. 3:25

    But what it does not give you is that

18. 3:28

    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 operational meets.

19. 3:45

    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.

20. 3:56

    Humans get registered, provisioned, um, authorized, monitored, investigated, and revoked on a day-to-day basis inside an org. Agents need the same life cycle from start to end. The only difference is speed, scale, and ambiguity.

21. 4:11

    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.

22. 4:33

    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?

23. 4:48

    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.

24. 5:00

    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?

25. 5:14

    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.

26. 5:33

    Um, they are being treated not as API keys five years, six years ago. They are becoming managed workers and managed entities.

27. 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 gets.

28. 5:57

    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.

29. 6:10

    In the agentic world, untrusted text can cause a trusted action. A ticket, a email, a document, um, a webpage, even a Slack message in today's world is not only data anymore, right?

30. 6:22

    To the model, it could potentially be an instruction which could have downstream actions.

31. 6:28

    In many agent systems, the attacker does not even need code execution. Sometimes they just need the text the agent will read.

32. 6:37

    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.

33. 6:55

    And the awkward part is that useful enterprise agents want all three. Um, a helpdesk 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.

34. 7:14

    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.

35. 7:25

    This is-- the-- this is probably the best example of that with the [REDACTED:username]. Um, and, you know, this is a production-grade version of what happened, right? Outside text, inside data, and an outbound path.

36. 7:37

    What this means is that [REDACTED:username] 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 a node, but a real enterprise company selling to real enterprises using the service.

37. 7:58

    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 signed-in user could see, and therefore, it made decisions, and it emitted data through Microsoft firewall, which ideally even internal employees should not have access to.

38. 8:20

    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.

39. 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.

40. 8:54

    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, Jason reported that the Replit agent ignored his explicit instructions for a code freeze, deleted live prod data, and misrepresented what happened.

41. 9:18

    Replit 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 enough to act, and it had effective production access.

42. 9:32

    What was missing was a deterministic break just before that.

43. 9:38

    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 or revoke trail.

44. 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.

45. 10:02

    [REDACTED:username] 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?

46. 10:19

    And that is why there is the security reframing, essentially. [REDACTED:username] 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.

47. 10:38

    Filters and guardrails are useful telemetry, obviously, but they're not the enterprise security boundary for high consequence actions like these ones. If an attacker-- If an attacker kept trying, one miss matters.

48. 10:52

    If an agent has broad authority, just one mistake mat-matters.

49. 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 has broad authority, that one mistake should live outside its circle of influence.

50. 11:16

    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.

51. 11:32

    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.

52. 11:43

    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.

53. 12:02

    The planner can plan but cannot call those tools. The executor can call these approv-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.

54. 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.

55. 12:35

    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?

56. 12:49

    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.

57. 13:08

    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.

58. 13:32

    That sounds abstract, um, so I have one small concrete example of this. A very simple password reset ticket.

59. 13:39

    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.

60. 13:51

    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.

61. 14:02

    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.

62. 14:17

    It gets a short-lived capability for this approved action, bound to the actor, to the subject, to the right audience, and TTL.

63. 14:26

    The recept 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.

64. 14:48

    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 chatbots. It means an identity for every actor, short-lived capability tokens for actions, policy gates that cannot be togged out of, receipts for everything, and clear revocation when something goes wrong.

65. 15:13

    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.

66. 15:30

    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.

67. 15:46

    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. [audience applauding] [outro jingle]