# You Didn't Ship a Bug. You Just Wrote It for a Human. Ravi Madabhushi, Scalekit | AI Engineer World's Fair 2026 | 12:50 Source: https://www.youtube.com/watch?v=lMCxVorb9wM Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/you-didnt-ship-a-bug-you-just-wrote-it-for-a-human Published: 2026-07-19 Tags: agents, mcp, security, tool-use ## TL;DR - Infrastructure built around human activity can fail when an agent repeats the same action at machine speed. - Agents need their own identity, a binding to the user they act for, and permissions tied to a specific job and context. - OAuth is a starting point, but agents need finer-grained authorization and complete visibility into every action. ## Summary Ravi Madabhushi describes a production incident caused by a human-centered assumption. Scalekit's system updated a user's last-seen timestamp on every tool call. An agent called the API far more often than a person would, creating repeated database pressure and latency spikes. That led Madabhushi to examine a larger problem in identity and authorization. Traditional systems assume that the person or service authenticating is also the actor, and that its behavior is deterministic. Agents break both assumptions. They act for users, yet may choose actions probabilistically and may receive broad access to every tool available to those users. Madabhushi argues that agents need their own identities, explicit links to their principals, least-privilege credentials, short-lived and context-specific permissions, and just-in-time authorization for elevated access. Teams also need an audit trail showing what happened, who acted, on whose behalf, who authorized it, and for how long. ## Key ideas ### A human-oriented timestamp became a machine-speed database load [00:20](https://www.youtube.com/watch?v=lMCxVorb9wM&t=20s) Scalekit's latency began spiking every 15 minutes. The cause was a last-seen timestamp in its identity and authentication infrastructure. It updated on every user action, which was reasonable for a person logging in occasionally. Once agents began calling the APIs, the update happened about 60 times faster and put unnecessary pressure on the database write system. The immediate fix was to batch the update once per second instead of writing on every call. For Madabhushi, the larger lesson was that a harmless human assumption can become an infrastructure problem when an agent repeats the action at machine speed. ### Traditional authentication assumes the authenticating identity is the actor [01:43](https://www.youtube.com/watch?v=lMCxVorb9wM&t=103s) Madabhushi describes two established patterns. A human application or script can use the user's API key, so the same user authenticates and acts. Alternatively, a service account gets its own identity and a fixed set of permissions. Passwords, API keys, web session tokens, and service accounts all follow the same basic model: permissions are set at registration, then every later action uses those permissions. This model worked because the programs using these credentials were written by people and behaved deterministically. Developers could inspect the code, and providers such as Google could review whether an application used its requested scopes appropriately. ### Agents separate the principal from the actor and remove behavioral certainty [06:41](https://www.youtube.com/watch?v=lMCxVorb9wM&t=401s) An agent usually acts on behalf of a user, so the user is the principal and the agent is the actor. Many systems do not express that relationship clearly, especially when they do not support OAuth. Agents also do not behave like fixed programs. An action taken today does not prove that the agent will take the same action on its next run. Madabhushi says teams often respond by giving the agent an identity and asking it to act for a user, or by making it act directly as the user. The second option is worse because it hides who is actually acting and makes the authorization boundary unclear. ### Broad tool exposure leaves the agent to decide what it may do [08:32](https://www.youtube.com/watch?v=lMCxVorb9wM&t=512s) Many MCP servers expose all tools available to a user or all tools supported by an application. The agent then decides which tools it can use. That means the agent sees the same tool surface whether it acts for one user or another, even when their responsibilities differ. Runtime checks may block some actions, but the agent can still select the wrong tool or attempt the wrong operation. Madabhushi argues that the available tool context must be limited according to the user who authorized the agent and the job the agent is meant to perform. ### Agent permissions need fine-grained limits on action, context, and time [09:13](https://www.youtube.com/watch?v=lMCxVorb9wM&t=553s) Madabhushi calls for permissions more precise than a scope such as whether a client can send email. An authorization system should be able to limit when an agent can act, which senders' emails it can read, which recipients it can contact, and which tools or jobs belong to its task. These controls should operate at the attribute, context, and principal levels. Permissions should also last only for the relevant operating period. Since agent workflows are probabilistic, broad scopes that might be acceptable for reviewed deterministic code are unsafe as a default. ### Least privilege and just-in-time authorization belong in the agent model [10:32](https://www.youtube.com/watch?v=lMCxVorb9wM&t=632s) Agents should receive only the access needed for their current task. If they need more, they should be able to request authorization at the time of need rather than holding broad permanent access. Madabhushi points to ref.tools, whose product gives coding agents context, as an example of a company that built its OAuth scoping around a product with no human actors. He presents this as evidence that agent-specific authorization is already an active product requirement, rather than a future concern. ### Auditability must identify every actor, principal, authorization, and duration [11:41](https://www.youtube.com/watch?v=lMCxVorb9wM&t=701s) A production system needs visibility into every agent action. Madabhushi says teams should know what the agent did, who took the action, on whose behalf it happened, who authorized it, when that authorization was given, what it allowed, and how long it lasted. Without that record and deterministic controls over what the agent can do, operators are left hoping the agent will not take an unintended action. His recommendation is to rethink systems designed for humans and APIs, use OAuth as a starting point, and add finer-grained controls that keep the agent acting on behalf of an identified user. ## Notable quotes - "The assumption that broke was how often would our system have to update this timestamp on every row." (01:22) - "But agents fundamentally break this assumption." (06:21) - "Agents are bound to do things whatever they can get a hold of." (10:20) - "Praying is not a strategy, as we all know." (12:03) ## Tools & references mentioned - Freshworks - Pipemonk - Salesforce - Databricks - HubSpot - Notion - Gmail - OAuth - SPIFFE - MCP - Google - ref.tools ## Who should watch - You are building an agent that calls existing APIs or MCP servers and want to know which human-centered assumptions may fail first. - Your authorization model gives an agent broad access to the same tools available to a user or application. - You need an audit trail that can distinguish the agent, the user it acted for, and the authorization behind each action.