{
  "video": {
    "id": "lMCxVorb9wM",
    "title": "You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit",
    "duration": 770,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer",
    "event_format": "Online"
  },
  "analysis": {
    "video_id": "lMCxVorb9wM",
    "title": "You Didn't Ship a Bug. You Just Wrote It for a Human. - Ravi Madabhushi, Scalekit",
    "one_liner": "Ravi Madabhushi (Scalekit) argues that identity infrastructure built on the assumption \"whoever authenticates is who acts, with permissions fixed at registration time\" collapses for non-deterministic agents, and that agents need their own identity bound to a principal plus attribute- and context-level scoping far finer than today's OAuth scopes.",
    "summary": "The talk opens with a production oddity — latency spiking rhythmically every 15 minutes — that traced back to agents hammering Scalekit's APIs and driving the per-user \"last seen\" timestamp update 60x faster than human traffic, pressuring the DB write path. That small broken assumption led Madabhushi to ask which authentication and authorization assumptions break entirely under agents: classic slots (human-with-API-key, and service account/SPIFFE/OAuth machine identity) both assume a deterministic program written by a human that can be code-reviewed and stays in its lane. Agents break both halves — principal and actor are no longer the same, many systems still lack OAuth so there is no on-behalf-of at all, and there is no determinism guaranteeing the agent will do tomorrow what it did today. He argues for agents with their own identity, permanently bound to the principal, least-privileged by default with just-in-time elevation, and full audit visibility into who acted, on whose behalf, who authorized it, when and for how long.",
    "key_points": [
      "A rhythmic 15-minute latency spike in Scalekit's identity platform turned out to be agent traffic updating the per-user \"last seen\" timestamp 60 times faster than human traffic would, creating unnecessary DB write pressure; the fix was batching the update at a one-second granularity instead of writing on every request.",
      "Most agents Scalekit's customers build have far more permissions and scopes than the agent's actual job requires — not from developer carelessness, but because it became the default pattern and existing primitives don't allow extremely fine-grained agent permissions.",
      "Only two pre-agent slots exist, neither designed for agents: a human acting through an app or script with their own API key (authenticating principal == acting actor), and the service-account/machine-identity model (SPIFFE, OAuth) where credentials and scopes are fixed at registration time.",
      "Those models held for decades because the machine ran a deterministic program written by a human — it could never do what it wasn't programmed to do, and the code could be inspected (he cites Google's developer-account security review reading your codebase before granting client ID scopes).",
      "Agents break the model twice: the principal is no longer the actor (requiring delegated, on-behalf-of access), and many systems still don't support OAuth so you can't even tell whether a program is acting for a user or the user is acting directly. Worse, there is no determinism — an agent doing something safely today is no guarantee for tomorrow or the very next run.",
      "Most MCP servers Scalekit has worked with don't limit tool context based on which user authorized the agent: they surface every tool the user has access to, or every tool the application supports, and let the agent decide — so the agent sees the same surface regardless of whom it acts for, and picks the wrong tool.",
      "Today's OAuth scopes are too coarse: Gmail asks only \"can this client send emails on your behalf,\" with no way to express \"can this agent act at this hour,\" \"read emails only from these senders,\" or \"send emails only to these recipients.\"",
      "This is presented as a problem of today, not a warning shot — agents have already deleted production databases — and customer ref.tools, whose product gives context to coding agents and has no human actors at all, built full OAuth scoping to handle it."
    ],
    "takeaways": [
      "Audit where human-era assumptions about request volume and write patterns break under agent traffic — batch per-request writes like last-seen timestamps rather than assuming human-paced frequency.",
      "Give agents their own identity (a client ID) that is bound to a principal at all times, rather than letting the agent act as the user — which he calls the worse of the two lanes.",
      "Scope agents at attribute, context and principal level with time-limited credentials, least privilege by default, and just-in-time authorization for elevated scopes — treat OAuth as a starting point, not the answer.",
      "Make MCP servers filter the tool surface by which user authorized the agent, instead of exposing every tool the user or application supports and relying on the agent's judgement plus runtime checks.",
      "Instrument complete audit visibility for every agent action: who took it, on behalf of whom, who authorized it, when the authorization was given, what it covered, and how long it lasts."
    ],
    "topics": [
      "agents",
      "authentication",
      "authorization",
      "oauth",
      "mcp",
      "identity",
      "least-privilege",
      "api-design"
    ],
    "tools": [
      "Scalekit",
      "Freshworks",
      "Salesforce",
      "Databricks",
      "HubSpot",
      "Notion",
      "Gmail",
      "Google",
      "OAuth",
      "SPIFFE",
      "MCP",
      "ref.tools"
    ],
    "quotes": [
      {
        "text": "this last seen update is happening 60 times faster than what it would, and that is creating unnecessary pressure in our DB write system.",
        "at": "01:10",
        "url": "https://www.youtube.com/watch?v=lMCxVorb9wM&t=70s"
      },
      {
        "text": "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.",
        "at": "07:39",
        "url": "https://www.youtube.com/watch?v=lMCxVorb9wM&t=459s"
      },
      {
        "text": "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.",
        "at": "10:30",
        "url": "https://www.youtube.com/watch?v=lMCxVorb9wM&t=630s"
      },
      {
        "text": "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.",
        "at": "12:03",
        "url": "https://www.youtube.com/watch?v=lMCxVorb9wM&t=723s"
      }
    ],
    "words": 2580
  },
  "summary_url": "/#lMCxVorb9wM",
  "transcript": {
    "html": "/transcripts/lMCxVorb9wM.html",
    "txt": "/transcripts/lMCxVorb9wM.txt",
    "vtt": "/transcripts/lMCxVorb9wM.vtt"
  }
}