AI Engineer

You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit

1731 summary words 8 min summary Watch video

Start with the signal

8 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Agent systems require a new authorization architecture because identities, permissions, and audit models designed for deterministic human-written software leave non-deterministic agents overprivileged and insufficiently attributable.
  • Why it matters: Any agent connected to operational systems, MCP tools, or third-party data can choose among permissions and tools far more broadly than its assigned task requires, turning conventional OAuth scopes and service accounts into an avoidable control-plane risk.
  • Best use: Use this as a security-design framing for OpenClaw and agent-enabled products, then translate its principles into an explicit agent identity, delegated-authority, tool-entitlement, just-in-time elevation, and audit design.

Executive Summary

Ravi Madabhushi argues that agent failures are often architectural rather than merely model-behavior bugs: systems were built around humans or deterministic programs, where the authenticating identity is normally the acting identity and permissions remain fixed from registration onward. Agents disrupt both assumptions. They frequently act on behalf of a user while possessing their own operational identity, and their next sequence of actions cannot be guaranteed simply by inspecting source code.

His concrete trigger was a ScaleKit performance anomaly: a “last seen” timestamp system built around human activity began receiving agent-driven updates roughly 60 times faster, producing rhythmic database-write and latency spikes every 15 minutes. Batching updates fixed that narrow issue, but it exposed a wider concern: hidden human-centric assumptions may become dangerous when agents become high-frequency actors.

The core security critique is that many MCP servers expose every tool available to a user—or even every tool an application supports—to the agent, rather than presenting only the tools appropriate to that user, task, and moment. Broad OAuth scopes such as the ability to send mail are inadequate for a probabilistic actor that may select an unintended available tool.

The proposed direction is least privilege by default, with a distinct agent identity continuously bound to the user principal it represents; highly granular permissions constrained by attributes, context, task, and time; just-in-time elevation for exceptions; and complete action visibility. OAuth remains useful as a starting point, but Madabhushi’s position is that it does not by itself provide the fine-grained, dynamic authorization agents need.

Key Takeaways

  • Claim: Human-oriented operational assumptions can fail under agent traffic even when the functional behavior appears harmless. | Evidence: ScaleKit saw latency spike rhythmically every 15 minutes because its per-user “last seen” field, designed around human activity, was updated about 60 times faster once agents began calling APIs; batching writes at a one-second level addressed the immediate database pressure. | Implication: Capacity, rate-limit, telemetry, and state-update designs should treat agents as potentially high-frequency autonomous actors rather than as human-like API users. | Caveat: This example demonstrates a performance and data-write assumption rather than a security exploit, but the speaker uses it as a warning that deeper identity and authorization assumptions may also be wrong.
  • Claim: Traditional authentication models presume that the authenticating party is the acting party and that its permissions are fixed and inspectable. | Evidence: Passwords, web sessions, API keys, and service accounts establish an identity and apply scopes assigned at registration; conventional machine-to-machine programs are deterministic because humans wrote their code and can review its intended behavior. | Implication: Do not model an agent merely as another API key, user session, or broadly privileged service account. | Caveat: Deterministic software and conventional OAuth/service-account systems have their own known security weaknesses; the claim is that agents introduce an additional, materially different problem.
  • Claim: Agents separate the actor from the principal and add behavioral non-determinism, so authorization must preserve delegated context for every action. | Evidence: An agent may access Gmail, Salesforce, or other systems on behalf of different users, while its actions can vary from run to run rather than staying within a fixed human-authored execution path. Madabhushi notes that many systems still lack usable OAuth or on-behalf-of support, obscuring whether a user acted directly or software acted for them. | Implication: Every downstream request should be attributable to both the agent identity and the originating user/principal, rather than collapsing the two into one identity. | Caveat: The transcript does not prescribe a specific token format or protocol implementation for maintaining this binding.
  • Claim: MCP tool surfaces commonly overexpose capabilities to agents, allowing the model to decide among tools that should never have been available for the current user or job. | Evidence: Madabhushi says most MCP servers his company works with surface all tools the user can access, or all tools an application supports, regardless of whom the agent is acting for; runtime checks may block some requests, but the agent still sees the same broad surface and may select the wrong tool. | Implication: Tool discovery itself should be policy-filtered by principal, delegated authority, task, and context—not treated as a harmless pre-authorization convenience. | Caveat: This is the speaker’s field observation, not a quantified industry-wide measurement, and well-designed MCP deployments may already filter tools and enforce policy server-side.
  • Claim: Broad OAuth scopes are insufficient for non-deterministic agents; permissions must be narrow, contextual, and temporary. | Evidence: A Gmail-like scope may only state that a client can send email on a user’s behalf, whereas the speaker argues an agent should be constrained by time, allowed senders or recipients, and purpose. He calls for attribute-, context-, and principal-level scoping tied to a specific agent goal or job. | Implication: Express authorization as a constrained operational entitlement—for example, an allowed action on named resources, under specified conditions, during a limited interval—rather than a standing application-wide grant. | Caveat: Fine-grained permissions impose policy-modeling and enforcement complexity, and the talk does not address how to balance that cost against usability or automation speed.
  • Claim: Least privilege needs just-in-time elevation and deterministic guardrails because agent mistakes are already an operational problem, not a future hypothetical. | Evidence: Madabhushi cites incidents in which agents have performed rogue actions such as deleting production databases and points to Ref.tools, whose product gives coding agents context and has built its authorization/scoping model around agents rather than human actors. | Implication: Default agent access should be deliberately insufficient for exceptional or destructive actions; escalation should require a fresh, narrowly scoped authorization decision. | Caveat: No incident details, root causes, or evidence tying those incidents to a particular authorization failure are provided.
  • Claim: Agent operations require audit records that establish who acted, for whom, under which authorization, and for how long. | Evidence: The speaker’s required visibility fields are: who took the action, on behalf of whom, who authorized it, when the authorization was granted, what it allowed, and its duration. | Implication: Build provenance and authorization-decision logging into the request path, so investigations and revocations can be performed from evidence rather than inferred from a shared token or agent log.

Detailed Brief

Authorization model implied by the talk

  • Claims: An agent should possess a distinct identity rather than impersonating its user outright.; The agent identity must remain bound to the principal whose authority it is exercising.; An agent’s accessible tools should be derived from its assigned goal or job, not solely from the maximum permissions held by its invoking user.
  • Evidence: Madabhushi contrasts two common but inadequate patterns: assigning an agent a client identity that is too broadly authorized, or allowing the agent to act directly as the user, which he considers worse.; He frames the desired state as deterministic authorization controls around a probabilistic workflow.
  • Caveats: The presentation is an architectural argument, not an implementation guide; it does not specify policy engines, token-exchange mechanics, approval UX, or MCP protocol extensions.; OAuth is characterized as a useful foundation, but no specific standard is claimed to fully solve agent authorization.
  • Implications: Treat delegated-agent authorization as a first-class control-plane domain, separate from generic API authentication.; Evaluate vendors and internal platforms on whether they can enforce policy before tool exposure and execution, not merely record activity afterward.

Notable Concepts & Terms

  • Actor vs. principal: The agent is the operational actor, while the user or organization whose authority it exercises is the principal; preserving both identities is central to attribution and policy.
  • On-behalf-of delegation: A mechanism for expressing that software is acting under a particular user’s authority rather than as that user or as an unqualified service account.
  • MCP server tool surface: The set of tools presented to an agent; the talk argues this surface must be filtered by current authority and task rather than broadly exposed.
  • Client identity / client ID: An OAuth-oriented identity assigned to software; insufficient on its own if it grants standing authority that is not bounded to a user, task, or time window.
  • Attribute-, context-, and principal-level scoping: Authorization granularity based on properties such as target resource, sender/recipient, time, task, user, and environmental conditions—not only coarse API scopes.
  • Just-in-time authorization: Obtaining a narrowly limited, temporary privilege only when an agent needs elevated access, instead of granting it permanently at setup.
  • Deterministic guardrails: Policy enforcement outside the probabilistic model that reliably constrains tools, actions, resources, and timing regardless of agent intent.
  • Ref.tools: A ScaleKit customer cited as an example of an agent-native product that provides context to coding agents and has had to build authorization/scoping accordingly.

Operator Notes / Why Ken Should Care

  • Create a required authorization tuple for every agent-initiated request: agent ID, principal/user ID, delegated grant ID, task or run ID, permitted action/resource constraints, issuance time, and expiry.
  • Audit each MCP integration for tools that are visible to the model but not necessary for the current task; move filtering and enforcement to the server/control plane rather than relying on prompts or model tool choice.
  • Replace standing broad credentials for destructive, external-communication, financial, or production operations with time-bounded grants and an explicit escalation path.
  • Add load tests that model agent call frequency and concurrency, including hidden per-request writes such as activity timestamps, usage counters, and audit records.
  • Require an investigation-ready event schema before expanding agent autonomy: actor, represented principal, authorizer, authorization decision, effective permissions, target, outcome, and grant expiry.

Source/Metadata

  • Title: You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit
  • Transcript words: 3675
  • Duration seconds: 770
  • Timestamp note: No timestamps or chapters were provided. The transcript repeats a substantial portion of the presentation after the closing remarks.
Search this video Resume transcript at 0%
Full transcript 2204 words · 16 min read
0:00

Hi, thank you so much for tuning in. I'm Ravi. I'm one of the co-founders of ScaleKit. Today, I'm going to talk about how you need to think architecturally from the ground up about building your applications, APIs, your MCP servers for agents, and how the human-focused architecture doesn't scale well for agents. A while back, we were looking at our performance and latency numbers. One thing that jumped out at us was how our latency was spiking every 15 minutes in a rhythmic manner. Nothing harmful, but just a curious thing for us to analyze.

0:17

What we noticed was very interesting. In our identity and authentication infrastructure platform, we have this little timestamp that we mark for every user to say, hey, when was the user last seen, or when was the user last active or last acted in our system, so that we can predictively say, hey, this user is an active user. This user is not so active. But one thing that we realized was this system was probably built for humans. When agents started hitting our APIs in the last 12 months or so, we realized that this last seen update is happening 60 times faster than what it would. That is creating unnecessary pressure in our dbWrite system.

0:29

Of course, it's a harmless thing. We were able to fix it very easily. We could just batch the update at a second level and not every single time we had to update it. That took us down a rabbit hole. The assumption that broke was how often our system would have to update this timestamp on every row. That's okay. It's just about speed. It's about latency, etc. But what I was worried about is, hey, what if some of our assumptions that we made about authentication and authorization need to be rewired and rethought completely when it comes to agents, because we would have designed earlier for humans as actors in mind?

0:41

Just to give you context, I worked on identity and authentication operation for the last 10 years, building an identity platform at Freshworks, which is being used by millions of daily users, hundreds and thousands of customers all over the world. But this is predominantly human users, right? Or, the way I think about APIs, APIs are also accessed by machines that are written by humans. That's not too bad, right?

0:46

But what I realized is the fundamental picture has changed drastically in the last three, four years or so. We have a unique ringside view to see how developers nowadays are building agents and how they're giving context to these agents with data from third-party applications like Salesforce or Databricks or HubSpot or Notion.

0:54

What we have realized is most of the agents our customers are building have way too many permissions and scopes than the agent's responsibility or the agent's job is. Again, it's not because the developers who are building the agents are careless, but somehow this became a default pattern of giving the agents what they need access to, and the existing primitives that we have don't let us give extremely fine-grained permissions to the agents. Now, I'll tell you how we ended up here, right? We predominantly have two slots, and neither of the slots was built for agents in mind.

1:05

There's a human who's accessing the application, either a web application or a mobile application or their own little script that they wrote, and they give it their API key so that their program can access data from the application. The fundamental principle here is it's the same user who is authenticating, and it's the same user who is acting, right?

1:14

The second slot is the traditional service account scenario or m2m account scenario, where you create a service account, you give it certain permissions, and then say this machine has its own identity. That's where the likes of SPIF and OAuth and all of that came into the picture, but you would give them certain credentials and say, hey, now this machine has access to whatever data that it needs at any single point of time. This is the existing pattern, right?

1:21

The fundamental philosophy that we have always maintained is whoever is authenticating is the one that is acting. Every action the program or the human takes is based on a fixed set of permissions that actor was granted at some time. If you take traditional authentication mechanisms for humans, including password, you just say, hey, if an identity has the same password that it was set at the time of registration, if they come back and if they present the same password again, then you say, okay, this is how I validate the identity. This is how I authenticate the human, and every action subsequently is tied to that human identity.

1:33

Again, the same is the case with API key, or the same is the case with web session tokens, or even the same case for service account. You define the permissions at the time of registration, and then every single time it acts based on the registration-time permissions and scopes. This is okay all this while because, for decades, the service account and OAuth principle even is working fine, even though there are their own problems. But it is still working fine because these machines are using a program in a deterministic way, by the way the human developer wrote that program.

1:44

So there are absolute guarantees about what the program could or the program won't do, but it is still intentional based on what the human wrote, right? In this particular case, again, if it is using API keys, then the actor and the principal is the same. Then there is some sort of delegated permission for the program to act based on what consent the user has granted. But the second one is the most important part, which is it's a deterministic program, and it always stays in its own lane. It can never do what it was not programmed to do, and you could inspect the code to say, okay, is the program doing what it is supposed to do?

1:55

Even if you apply for a Google developer account and then ask for client ID and you need to access sensitive scopes, you have to go through a security review. What they're doing is looking at your code base to say, are you doing enough checks? Are the appropriate practices in place? So these programs are deterministic. These programs behave the exact same way a developer-programmed program can work.

2:08

But agents fundamentally break this assumption, right? First of all, in the case of agents, the principal is not the same as an actor. You need to give delegated access so that the agent can act on behalf of the user. Agent can access the user's Gmail. Agent can access the user's Salesforce data. Whatever the case may be. But again, unfortunately, not a lot of systems even today support OAuth. So here again, there is no on-behalf-of principle that is working. So you don't even know if there is a program that is acting on behalf of the user or the user acting by themselves, right? That's a fundamental problem.

2:22

The second problem is even more dangerous, which is right now the program is not written by human. There is no determinism baked in to say what the agent will do or won't do. Just because an agent does certain things today, you can't be 100% certain that the agent can do the same or the exact same thing tomorrow, the day after, or even in its next immediate run, right?

2:30

Because of this non-deterministic nature of the agent, we usually pick one of the two lanes, right? You give a specific identity to the agent, which is what we call as client ready in the context of OAuth, and then say, you act on behalf of this particular user, or we go back to the agent acts as the user, which is even worse. The fundamental reason why I'm harping on the same thing is because when an agent is acting on behalf of user one versus user two or user three, the agent needs specific permissions based on the user's context.

2:43

Now, OAuth solved this perfectly fine by saying, hey, the user will grant specific scopes or permissions to the agent. So the agent is acting on behalf of the user. It can't do everything, but the agent will only do certain things. Now, in the kind of world that we're looking in, most of the MCP servers that we work with don't actually limit the tool context access to the agent based on which user authorize the agent. They typically surface all the tools that the user has access to, or all the tools that the application can even support, and then let the agent determine what they can or cannot do.

3:01

Now the agent ends up picking the wrong tool, doing the wrong things. Maybe there is some runtime check in the application that prevents some of these things, but the agent is still seeing the same surface regardless of whom it is acting for. Two things that we need to solve for: one is the actor, in this case an agent, has to be bound to the principal at all times. And the agent should have its own identity. Agent should have extremely fine-grained credentials, not the OAuth scopes that we are seeing today.

3:14

If you inspect the scopes for some of these applications, even very popular applications like Gmail, it will say, can this client send emails on your behalf? There is no extremely fine-grained scoping to say, can this agent act at this hour? Can this agent read emails only from these senders? Can this agent send emails to only this recipient? The reason why that is important is because, again, we spoke about this earlier. In the context of non-deterministic agent workflows, it's extremely important that the agent should have permissions for a limited amount of time that they are operating in.

3:28

Number one, every agent has a goal. Every agent has a job. So you should be able to deterministically say that this agent should have access only to those tools or only to those jobs it has access to. Gone are the days when the broad-scoped OAuth scopes that we defined were okay because, in that case, the developer was writing a deterministic application. You can review the code to make sure that he's not doing anything sinister.

3:38

But in the case of agents, it's extremely non-deterministic. It is probabilistic. Agents are bound to do things with whatever they can get a hold of. So, in the context of when you're giving access to the agents, you should be in a position to give extremely fine-grained scopes. It should be at an attribute-level scoping. It should be context-level scoping. It should be principal-level scoping. So all of that is extremely important. Again, I think everyone agrees that agents should be least privileged by default, and they should be able to ask for just-in-time authorization if they want elevated scopes.

3:52

Now, the reason why we're talking about this is because it's not some futuristic thing. It is happening today. We have seen enough incidents where agents end up doing rogue things. They end up deleting production databases and stuff like that. So how do you put deterministic guardrails in place is an important problem to be solved right now. Again, one of our customers, Ref.tools, they don't even have humans as actors. Their predominant product is about how to give context to coding agents so they can do their job effectively. So they built the entire OAuth scoping, how do you do things the right way, and things like that.

4:03

So the reason why I give this example is not to say that this is a warning shot, but this is a problem of today and not for tomorrow. Before I go, you have to have absolute visibility into what your agent can do. Every action that's taken in your system: who took it, on behalf of whom, and who authorized it, when was the authorization given, what authorization was given, how long is it given for.

4:15

If you don't have visibility into all these actions at every single time, and if you can't deterministically control what your agent can or cannot do, then you're just praying that the agent doesn't end up doing what it's not supposed to do. And praying is not a strategy, as we all know.

4:20

One last thing to take away. If you architected so far with humans and APIs in mind, you need to start rethinking about how you need to give deterministic guardrails and deterministic authorization controls to the agent. OAuth is a good place to start, but you need something beyond OAuth to make sure that the agents have extremely fine-grained access controls and agents are always acting by themselves on behalf of certain users. Thank you so much for your time. password, you just say, hey, if an identity has the same password that it was set at the time of registration, if they come back and if they present the same password again, then you say, okay, this is

4:43

how I validate the identity. This is how I authenticate the human and every action subsequently is tied to that human identity. Again, the same is the case with API key or the same is the case with web session tokens or even the same case for service account. You define the permissions at the time of registration and then every single time it acts based on the registration time permissions and scopes. Now, this is okay all this while because for decades, the service account and OAuth principle even is working fine, even though there are their own problems, but it is still working fine because these machines are

5:25

using a program in a deterministic way by the way the human developer wrote that program. So there is absolute guarantees about what the program could or the program won't do, but it is still intentional based on what the human wrote, right? In this particular case, again, if it is using API keys, then the actor and the principal is the same. Then there is some sort of a delegated permission for the program to act based on what consent the user has granted. But the second one is the most important part, which is it's a deterministic program and it always stays in its own lane. It can never do what

6:05

it was not programmed to do and you could inspect the code to say, okay, is the program doing what it is supposed to do? Even if you apply for a Google developer account and then ask for client ID and you need to access sensitive scopes, you have to go through a security review. So what they're doing is looking at your code base to say, are you doing enough checks, the appropriate practices in place. So these programs are deterministic. These programs behave the exact same way a developer program can work. But agents fundamentally break this assumption, right? First of all, in the case of

6:37

agents, the principle is not the same as an actor. You need to give delegated access so that the agent can act on behalf of the user. Agent can access the user's Gmail. Agent can access the user's Salesforce data. Whatever the case may be. But again, unfortunately, not a lot of systems even today support OAuth. So here again, there is no on behalf of principle that is working. So you don't even know if there is a program that is acting on behalf of the user or the user acting by themselves, right? That's a fundamental problem. The second problem is even more dangerous, which is right now the program is not

7:15

written by human. There is no determinism baked in to say what the agent will do or won't do. Just because an agent does certain things today, you can't be 100% certain that the agent can't do the same or the exact same thing tomorrow day after or even it's the next immediate run, right? Because of this non-deterministic nature of the agent, we usually pick one of the two lanes, right? You give a specific identity to the agent, which is what we call as client ready in the context of OAuth and then say, you act on behalf of this particular user or we go back to the agent acts as the user, which is even

7:56

worse. The fundamental reason why I'm harping on the same thing is because when an agent is acting on behalf of user one versus user two or user three, the agent needs specific permissions based on the user's context. Now, OAuth solved this perfectly fine by saying, hey, the user will grant specific scopes or permissions to the agent. So the agent is acting on behalf of the user. It can't do everything, but the agent will only do certain things. Now, in the kind of world that we're looking in, most of the MCP servers that we work with don't actually limit the tool context access to the agent based on which user authorize the agent. They typically surface

8:44

all the tools that the user has access to or all the tools that the application can even support and then let the agent determine what they can or cannot do. And now the agent ends up picking the wrong tool, doing the wrong things. Maybe there is some runtime check in the application that prevents some of these things, but the agent is still seeing the same surface regardless whom it is acting for. Now, two things that we need to solve for. One is the actor, in this case an agent, has to be bound to the principle at all times. And the agent should have its own identity. Agent should have extremely fine

9:22

grained credentials, not the OAuth scopes that we are seeing today. If you inspect the scopes for some of these applications like even very popular applications like Gmail, it will say, can this client send emails on your behalf? There is no extremely fine grained scoping to say, can this agent act at this hour? Can this agent read emails only from these senders? Can this agent send emails to only this recipient? The reason why that is important is because, again, we spoke about this earlier. In the context of non-deterministic agent workflows, it's extremely important that the agent

9:59

should have permissions for a limited amount of time that they are operating in. Number one, every agent has a goal. Every agent has a job. So you should be able to deterministically say that this agent should have access only to those tools or only to those jobs it has access to. So gone are the days when the broad scoped OAuth scopes that we defined is okay because in that case, developer was writing a deterministic application. And you can review the code to make sure that he's not doing anything sinister. But in the case of agents, it's extremely non-deterministic. It is probabilistic. Agents are

10:34

bound to do things whatever they can get a hold of. So in the context of when you're giving access to the agents, you should be in a position to give extremely fine-grained scopes. It should be at an attribute level scoping. It should be context level scoping. It should be principle level scoping. So all of that is extremely important. Again, I think everyone agrees that agents should be least privileged by default and they should be able to ask for just-in-time authorization if they want elevated scopes. Now, the reason why we're talking about this is because it's not some futuristic thing. It is happening today.

11:09

We have seen enough incidents where agents end up doing rogue things. They end up deleting production databases and stuff like that. So how do you put deterministic guardrails in place is an important problem to be solved right now. Again, one of our customers, Ref.tools, they don't even have humans as actors. Their predominant product is about how to give context to coding agents so they can do their job effectively. So they built the entire OAuth scoping. How do you do things the right way and things like that. So the reason why I give this example is not to say that this is a warning shot, but this is a problem

11:42

of today and not for tomorrow. Before I go, you have to have absolute visibility into what your agent can do. Every action that's taken in your system, who took it, on behalf of whom, and who authorized it, when was the authorization given, what authorization was given, how long is it given for. If you don't have visibility into all these actions at every single time and if you can't deterministically control what your agent can or cannot do, then you're just praying that the agent doesn't end up doing what it's not supposed to do. And praying is not a strategy as we all know. One last thing to take away. If you

12:21

architected so far with humans and APIs in mind, you need to start rethinking about how you need to give deterministic guardrails and deterministic authorization controls to the agent. And OAuth is a good place to start, but you need something beyond OAuth to make sure that the agents have extremely fine grain access controls and agents are always acting by themselves on behalf of certain users. Thank you so much for your time.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note