Video summary

A Conversation With Harish Peri

Main summary

Key takeaways

Technology

Overview

This interview focuses on securing enterprise AI agents—especially the authorization, identity, access scoping, auditability, and governance needed to prevent agents from causing data breaches, runaway actions, or compliance failures.

Core problem / what’s “disrupting sleep”

  • AI agents are already deployed across enterprises (e.g., local coding agents, browser-based agents, and agents integrated into platforms like Salesforce/AWS).
  • While organizations may have “model guardrails,” the interview emphasizes that:
    • The model itself isn’t the risk
    • The risk comes from the agent’s ability to take actions
  • Key pain points teams worry about:
    • Secure agent identity
    • Authorization and fine-grained access
    • Preventing harmful outcomes even from hallucinations or compromised behavior
    • Ensuring agents don’t access sensitive production data improperly

Transparency + control vs. discovery

The conversation frames security as requiring both:

  • Transparency / observability
    • e.g., knowing how many agents exist and what they do
  • Control / governance
    • being able to restrict and stop agents when needed

A debate is mentioned: discovery vs governance. The speaker’s stance is that with agents, it’s often more important to control a smaller number of high-blast-radius agents than to only discover everything.

Compliance & audit requirements (transaction-level proof + chain of custody)

Agents create new compliance expectations, including the ability to prove:

  • Who/what accessed a resource (agent vs. user) at a transaction level
  • The full chain of custody:
    • user prompt → agent → delegated sub-agent(s) → application/data accessed

This is presented as a global, under-hyped regulatory direction: security teams need audit-ready evidence of access paths.

Protocols won’t arrive fast enough; solution must work now

  • Ideal future: a shared industry protocol where every agent action is tied to a discrete identity and sent as a signed, attributable request (token exchange).
  • But because deployment is already happening, the approach must work today, not later.

Octa for Agents: central authorization + gateway model

The speaker describes a product approach (Octa for Agents) centered on:

Centralized enterprise agent authorization

Agents should be managed centrally when they:

  • access multiple sensitive resources
  • are used by multiple people/users

Separation of duties / layered defense

  • Assign agents unique identities that are independent of model behavior
  • Use a central platform to issue authorization/access tokens and enforce permissions

Gateway as the traffic hub / authorization broker

  • Agents route tool calls through an agent gateway
  • The gateway checks whether the agent/user request is allowed (scope/policy enforcement)
  • Authorization uses token exchanges rather than a single “super token”
  • The example references RFC 693 for token exchange concepts

Kill switch / containment

Because the system is the central issuer/authorizer, it can:

  • shut off agent access when risk is detected

The kill switch can be executed at the identity/agent level, impacting the access graph (stopping related access paths).

Agent-to-agent and scope escalation risk

  • The “supervisor agent → sub-agent” pattern increases complexity.
  • A central concern is scope escalation, where a sub-agent expands permissions due to:
    • delegation patterns
    • prompt injection
    • spoofing

The system must enforce scopes across hop-by-hop calls:

  • user → supervisor agent → sub-agent → resource

A product announcement referenced agent-to-agent connections, which increases access-graph complexity but aims to enable controlled delegation.

Discovery + fast rollout under “board mandate” timelines

Because enterprises often move slowly, the speaker stresses speed (days, not weeks/months).

Discovery capabilities

  • Detect agents in the environment
  • Includes partnerships (example: CrowdStrike Falcon for discovering local agents)

Typical rollout workflow

  1. Discover agents
  2. Register them centrally and assign identity
  3. Route tool calls through Octa’s gateway
  4. Enforce centralized policies via tokens at runtime

Setup is described as roughly a few hours to a couple days, depending on coordination, scale, and internal involvement.

“Human in the loop” skepticism

The speaker argues that putting humans in the loop for every action defeats agent usefulness and speed.

Instead:

  • Humans should be involved only for high-sensitivity transactions
  • Authorization/control layers should handle routine checks quickly

Risk signals and unified zero-trust enforcement

Kill switch behavior is driven by unified risk telemetry, including:

  • prompt injection signals
  • data exfiltration signals
  • sensitive data tagged accesses
  • anomalous network traffic patterns

Central thesis: enforce “zero trust for agents” at the identity/authorization layer, so detected risk can actually shut the agent off (“turn the faucet off”).

Examples / incidents referenced

  • A “mugging face” style incident is used to illustrate that providers may not realize agents can run undesired actions for days.
  • The implication: agents do more than the model predicts—they execute actions that must be authorized.
  • Authorization gateways prevent the “agent as the bouncer” problem where no one blocks unauthorized tool calls.

Main speakers / sources

  • Daniel (interviewer)
  • Harish Peri (guest; product/security discussion around Octa for Agents)

Original video