Conference talk by Ravi Madabhushi (Scalekit) about production failures caused when AI agents interact with infrastructure designed for human users. A demo agent connecting to tools like Gmail and Calendar strained a production database because a "last seen" timestamp designed for human login frequency was updated at machine-speed. The talk argues such issues are design assumptions, not bugs, cites that 60% of production LLM errors trace to rate limits, and discusses treating agents as first-class principals in infrastructure design. # Channel Presentation Observations ## Speaker Identity & Explicit Self-Description - The speaker introduces himself directly: **"I'm Ravi, I'm one of the co-founders of Scale Grid"** (transcript opens; the title gives the name as "Ravi Madabhushi, Scalekit"). - He claims deep domain experience: **"I worked on identity and authentication operations for the last 10 years building an identity platform at Freshworks, which is being used by millions of daily users."** - He positions his company as an **identity and authentication infrastructure platform**: "in our identity and authentication infrastructure platform, we have this little timestamp…" ## Claimed Scope - The talk covers **architecting applications, APIs, and MCP servers for AI agents**, specifically why "human-focused architecture doesn't scale well for agents." - Topics demonstrated in the transcript: - **Authentication/authorization rethinking for agents** (principal vs. actor separation, delegated access) - **Fine-grained, just-in-time scoping** beyond OAuth scopes - **Deterministic guardrails and visibility/auditability** for agent actions - **MCP server permission design** (tool-context access per authorizing user) ## Claimed Positioning / Authority Signals - Claims a **"unique ringside view"** into how developers build agents: "how developers nowadays are building agents and… giving context to these agents with data from third-party applications like Salesforce or Databricks or HubSpot or Notion." - Cites a **named customer example (ref.tools)** to ground the problem: "One of our customers, ref.tools, they don't even have humans as actors." - Uses an internal war story (latency spiking every 15 minutes from "last seen" timestamp updates running "60 times faster" due to agents) as demonstration of real operational experience. ## Observable Presentation Style - **Talk/presentation format**: opens with "Hi, thank you so much for tuning in," states a thesis, walks through a problem narrative, and closes with explicit takeaways ("One last thing to take away…"). - **Memorable framing devices**: the title's hook ("You didn't ship a bug. You just wrote it for a human") and the closing aphorism **"praying is not a strategy."** - **Practitioner audience assumed**: discussion of OAuth, SPIFFE, service accounts, MCP servers, DB write batching, and security reviews assumes developer/architect-level familiarity. ## Intended Audience (Observable) - **Developers and architects** building agentic applications — evidenced by phrases like "how developers nowadays are building agents" and "the existing primitives that we have don't let us give extremely fine-grained permissions." - **Identity/security practitioners**, given sustained focus on authentication, authorization, scopes, and audit visibility. ## Claims vs. Demonstrated Patterns - **Creator claim**: Scalekit/Scale Grid operates an identity and authentication platform with agent-facing customers (supported by the ref.tools customer mention and the internal latency anecdote). - **Creator claim**: agent permission overreach is widespread ("most of the agents our customers are building have way too permissions and scopes than the agent's responsibility"). - **Demonstrated**: technical depth in identity infrastructure, structured argumentation from a concrete incident to architectural recommendations. - **Not evidenced**: no transcript claim about broader channel content, publishing cadence, or video series context. # Delivery Observations: Ravi Madabhushi — Scalekit ## Tone & Register - **Conversational, low-key technical talk**: speaks as an engineer sharing a discovery, not a formal lecture. - Opens with understatement: *"Nothing harmful, but just a curious thing for us to analyze."* - Later downplays incidents: *"We were able to fix it very easily."* - **First-person framing throughout**: heavy use of "we," "I," "our" — anecdote-driven, e.g., *"we were looking at our performance and latency numbers."* ## Vocabulary & Recurring Terms - Distinctive repeated jargon cluster: - **"fine-grained"** — appears repeatedly: *"extremely fine-grained permissions,"* *"extremely fine-grained credentials,"* *"extremely fine-grained scopes,"* *"attribute level scoping"* - **"deterministic" vs. "non-deterministic"** — the talk's central contrast: *"it's a deterministic program, and it always stays in its own lane"* vs. *"it is extremely non-deterministic, it is probabilistic."* - **Principal / actor / on behalf of** — repeated auth-specific terminology: *"whoever is authenticating is the one that is acting,"* *"the principal is not the same as an actor."* - Named technologies used as anchors: **OAuth, SPIFFE, MCP, Gmail, Salesforce, Databricks, HubSpot, Notion, Freshworks**. ## Teaching Habits & Structure - **Story-first opening**: begins with a concrete latency mystery (*"latency was spiking every 15 minutes in a rhythmic manner"*) before abstracting to the thesis. - **Contrast as the main teaching device**: humans/APIs vs. agents, deterministic vs. probabilistic, broad scopes vs. fine-grained scoping — repeated structurally, not just lexically. - **Hypothetical quoted dialogue** to explain systems: *"you just say, 'Hey, if an identity has the same password…'"*; *"say, 'Hey, now this machine has access to whatever data that it needs.'"* This "you say, 'Hey…'" pattern recurs multiple times. - **Credibility-establishing aside**: *"I worked on identity and authentication operations for the last 10 years… at Freshworks."* - **Concrete customer example** near the end: *"one of our customers, ref.tools."* - **Enumerated prescriptions**: *"Two things that we need to solve for. One is… the agent should have its own identity."* ## Rhetorical Patterns - **Conversational tag "right?"** used frequently as a comprehension check: *"That's not too bad, right?"*, *"And this is the existing pattern, right?"*, *"But agents fundamentally break this assumption. Right?"* - **Rhetorical questions as exposition**: *"Now, I'll tell you how we ended up here, right?"* - **Repetition for emphasis** on his core worry: *"The fundamental reason why I'm harping on the same thing is because…"* - **Memorable closing aphorism**: *"you're just praying that agent doesn't end up doing what it's not supposed to do. And praying is not a strategy, as we all know."* - **Urgency framing**: *"this is a problem of today and not for tomorrow."* ## Uncertainty Notes - Fillers and self-corrections suggest lightly rehearsed delivery: *"like Salesforce or or Databricks,"* *"what they are can or cannot do"* — plausible transcription artifacts, so this is stated with low confidence as a delivery trait. - Occasional run-on sentences with repeated conjunctions (*"But, what I was worried about…"*) may reflect either live speaking style or transcript punctuation; attribution uncertain. # Position Record: "You Didn't Ship a Bug. You Just Wrote It for a Human." — Ravi Madabhushi, Scalekit ## Speaker - **Ravi Madabhushi**, co-founder of Scalekit (self-identified as "Scale Grid" in transcript), with ~10 years in identity/authentication, previously building an identity platform at Freshworks. ## Core Thesis - Human-focused architecture does not scale for agents; authentication/authorization assumptions must be re-architected ground-up for agent actors. ## Evidence & Claims ### The "last seen" latency incident - Rhythmic latency spikes every 15 minutes in their identity platform; traced to a "last seen" timestamp updating **60x faster** once agents began hitting their APIs, pressuring DB writes. - Fix was simple: batch updates at the second level. Framed as a "rabbit hole" prompting deeper concern. ### Agents are over-permissioned - From a "ringside view" of customer agents using third-party data (Salesforce, Databricks, HubSpot, Notion), most agents hold **far more permissions/scopes than their job requires**. - Not carelessness — it became a default pattern because existing primitives don't support fine-grained agent permissions. ## Historical Model: Two Slots (Built for Humans) 1. **User + API key/script**: same user authenticates and acts. 2. **Service accounts** (SPIFFE, OAuth): machine gets its own identity and credentials with defined permissions. Underlying philosophy stated: **"whoever is authenticating is the one that is acting"**; permissions are fixed at registration time (passwords, API keys, session tokens, service accounts all follow this pattern). ### Why this worked historically - Traditional programs are **deterministic**, written by humans; they "always stay in their own lane." - Code inspection is possible — e.g., Google developer security reviews examine codebases before granting scopes. ## Why Agents Break the Model - **Principal ≠ actor**: agents need delegated access (Gmail, Salesforce) — yet many systems don't even support OAuth, so you can't distinguish an agent acting on behalf of a user from the user directly. - **Non-determinism**: no guarantee the agent repeats today's behavior tomorrow or even the next run. Agents are "probabilistic," "bound to do things whatever they can get a hold of." - **MCP server critique**: most MCP servers they've worked with don't limit tool context by authorizing user — they surface all tools and let the agent self-determine, leading to wrong tool selection; runtime app checks are insufficient because the visible surface is identical regardless of principal. ## Proposed Requirements - Agents must be **bound to the principal at all times** and have **their own identity**. - **Extremely fine-grained credentials beyond OAuth scopes** — attribute-level, context-level, principal-level scoping. Example: Gmail scopes only allow "send email on your behalf" rather than time-window, sender-restricted, or recipient-restricted grants. - **Time-limited permissions** matching the agent's operating window; each agent's access limited to its specific goal/job. - **Least privilege by default** with **just-in-time authorization** for elevated scopes. - **Full visibility/auditability**: every action — who took it, on behalf of whom, who authorized, what/when/how long the authorization lasted. ## Supporting Examples - Rogue-agent incidents **already happening**, including agents "deleting production databases" — framed as a today problem, not futuristic. - Customer **ref.tools**: no human actors; product gives context to coding agents; built proper OAuth scoping. ## Closing Positions - > "If you can't deterministically control what your agent can or cannot do, then you're just praying that agent doesn't end up doing what it's not supposed to do. And praying is not a strategy." - OAuth is "a good place to start," but **something beyond OAuth** is needed for fine-grained agent access control. ## Preserved Qualifications - The latency incident is explicitly described as **harmless** and easily fixed — a curiosity, not a breach. - Over-permissioning is attributed to **default patterns and primitive limitations**, not developer carelessness. - Speaker acknowledges OAuth "solved this perfectly fine" for delegated user scopes, and service accounts/OAuth "still working fine" for decades despite known problems — the critique targets their inadequacy for non-deterministic agents specifically. # Speaker Attribution & Provenance Record ## Video **Title:** You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit **Video ID:** `01a15ca8-76de-7a63-b93d-1654e6c9b159` ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Ravi Madabhushi** | Creator / presenter (self-identified) | *"I'm Ravi, I'm one of the co-founders of Scale Grid."* — single-speaker talk throughout | **Note:** Transcript is the sole source; the video title identifies him as **Ravi Madabhushi, Scalekit**, while the speaker says "Scale Grid" (likely a transcript rendering of "Scalekit"). No other speakers, guests, or narrators appear. ## Speaker Self-Reported Provenance - **Credentials claim (speaker's own):** 10 years in identity/authentication operations; built an identity platform at **Freshworks** used by millions of daily users. - **First-party anecdotes (unverifiable, from speaker):** - Latency spikes every 15 minutes traced to a "last seen" timestamp updating 60× faster under agent traffic. - Agents built by their customers hold excess permissions/scopes relative to their jobs. ## Referenced Third-Party Sources & Claims - **Named third-party products/platforms:** Salesforce, Databricks, HubSpot, Notion, Gmail, ref.tools, SPIFFE, OAuth, Google developer account security review, MCP servers. - **Third-party claims:** - **ref.tools** — customer example: no human actors; built OAuth scoping for coding-agent context access. - **MCP servers** — speaker's observation that most do not limit tool context by authorizing user. - **Gmail scopes** — example of coarse-grained delegation ("send emails on your behalf"). - **Unattributed claims:** *"We have seen enough incidents where agents end up doing rogue things… deleting production databases"* — no cited source or incident named. ## Promotional Segments - **Flagged:** The talk repeatedly references **Scalekit's** platform ("our identity and authentication infrastructure platform", "the MCP servers that we've worked with", customer example ref.tools). This functions as indirect company/product promotion, though no explicit call-to-action appears. ## Availability & Metadata Notes - **Curated metadata:** Not supplied (no comment availability, chapters, or description metadata provided). - **Uncertainty:** Company name discrepancy ("Scale Grid" spoken vs. "Scalekit" in title) is unresolved from available sources. Hi, thank you so much for tuning in. I'm Ravi, I'm one of the co-founders of Scale Grid. 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. So, a while back, we were looking at our performance and latency numbers, and one thing that kind of 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. What we noticed was very interesting. So, 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 primarily built for humans, but 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, and that is creating unnecessary pressure in our DB write system. So, of course, it's a harmless thing. We were able to fix it very easily. We would just batch the update at a second level and not at every single time we had to update it. That kind of took us down a rabbit hole. So, the assumption that broke was how often would our system have to update this timestamp on every row, and 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, 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?" Now, just to give you a context, I worked on identity and authentication operations 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 at best, APIs. But, the way I think about it is APIs are also accessed by machines that are written by humans. That's not too bad, right? 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 or Databricks or HubSpot or Notion. What we have realized is most of the agents our customers are building have way too 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 \[snorts\] 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. There's a human who's acting 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. This is all the fundamental principle here is it's the same user who is authenticating, and it's the same user who's acting, right? And the second slot is the traditional service account scenario or end-to-end 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 SPIFFE and and OAuth and all of that came into 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." And this is the existing pattern, right? So, the fundamental philosophy that we've always maintained is whoever is authenticating is the one that is acting. Every action the program or the human takes is based on 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. 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's still working fine because these machines are 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 what 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 that 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 it was not programmed to do. And you could inspect the code to say, "Okay, is the program doing what it's supposed to do?" Even if you apply for a Google developer account, and then ask for client ID, and you need to access these scopes, you have to go through a security review. So, what they're doing is they're looking at your code base to see, "Are you doing enough checks? The appropriate practices in place?" So, these programs are deterministic. These programs behave the exact same way a developer programmed them to work. 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, and 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 principal 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 written by human. There is no determinism baked in to say what the agent will do or won't do. Right? 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 if it's the next immediate run. Right? Because of this non-deterministic nature of 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 ID 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. Now, the OAuth solved this perfectly fine by saying, hey, the user will grant specific scopes or permissions to the agent. So, when 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 the world that we're living in, most of the MCP servers that we've worked with don't actually limit the tool context access to the agent based on which user authorized 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 are can or cannot do. And now the agent ends up picking the wrong tool, doing 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 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. If you inspect the scopes for some of these applications, like even very popular applications like Gmail, it'll say, can this client send emails on your behalf? There's 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 recipients? 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 limited amount of time that they're 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 auth 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 is extremely non-deterministic, it is probabilistic. Agents are 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 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. 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 that 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 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 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 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-grained access controls, and agents are always acting by themselves on behalf of certain users. Thank you so much for your time.