DEV Community: Subramanyan Balakrishnan

Why OAuth Scopes Aren't Enough for AI Agents (And why my LLM told me to walk my car)

Subramanyan Balakrishnan — Mon, 01 Jun 2026 10:33:15 +0000

Take a look at this prompt I recently ran through a lightweight model.

"I need to wash my car, the car wash is just 50 meters from my home. Should I take my car or go by walk?"

The model gave me a beautifully formatted, highly articulate response explaining why I should leave my car at home and walk to the car wash to save on fuel and cold-start emissions.

It's a hilarious, easily spottable logical failure. But as developers, it should also terrify us a little bit.

We are rapidly moving away from isolated chat interfaces and shifting toward building autonomous AI Agents. Whether you are orchestrating these workflows with LangGraph or a custom TypeScript loop, we are suddenly giving these non-deterministic models the agency to execute tool calls, hit our infrastructure APIs, and manipulate databases.

The Problem with Deterministic Auth for Non-Deterministic AI
If you are building an agent today, how are you securing its access?

Most of us default to what we know: API keys and OAuth scopes. But standard OAuth scopes like read, write, or admin were designed for deterministic software executing predictable routines.

They are entirely insufficient for AI.

If you give an agent a token with write access, the authorization server doesn't care why the agent is making a request. If a high-accuracy frontier model hallucinates and confidently decides to issue a destructive command, standard auth will happily validate the token and execute the blast radius.

You cannot take trust or security for granted when the reasoning engine is prone to unpredictable logical collapse.

Building an Agent Access Security Broker (AASB)
We realized that while you can't "fix" an LLM's reasoning, you absolutely must control its boundaries. That is why we are building SecuriX.

Instead of building a consumer wrapper, we designed SecuriX from the ground up as a B2B infrastructure API layer. It acts as an Agent Access Security Broker—a specialized proxy sitting between your AI agents and your backend services (Enterprise Data).

How we are tackling this:

Policy-as-Code: We are utilizing Open Policy Agent (OPA) and Rego. Instead of relying on broad scopes, you write granular Rego scripts that intercept and filter API tool calls at the network proxy layer.

Mathematical Boundaries: You define exact, mathematical boundaries for what parameters, values, and endpoints an agent can touch based on the specific context of the prompt.

Draft-Only Enforcement & Audit Trails: You can test policies in a "Draft-Only" mode to see how agents behave against your rules without breaking production, all backed by a Trust Portal with complete audit trails and instant kill switches.

Even if your underlying model gets confused—like telling a user to walk their car to the car wash—your infrastructure remains secure because the agent is physically bound by the Rego policies you've defined.

We are Building in Public
Security tooling for AI is still the wild west, and we want to get this right.
I’d love to hear from other builders in the community: When you are granting your AI agents access to your APIs, how are you currently handling guardrails? Are you hardcoding checks, or just praying the system prompt holds up?

Let's discuss in the comments. 👇

7 Reminders Before You Paste That Internal Log into an AI Chat

Subramanyan Balakrishnan — Thu, 30 Apr 2026 00:11:04 +0000

We all use AI to code faster, debug, and format our work. But the copy-paste shortcut is the easiest way to accidentally leak sensitive data. Take a breath and review exactly what is on your clipboard before feeding it to an AI.

Prompts are just another form of data, and your favorite AI tool is built by someone else. Don't accidentally make your company's private architecture their free training material.

To help spread this mindset across both engineering and broader non-technical teams, we’ve spent the last week creating a simple, visual AI Security Awareness campaign. No heavy jargon, just straightforward reminders on safe AI usage.

We've uploaded the first 7 posters. They are free to download and drop into your company's Slack/Discord channels to keep data safety top of mind.

Grab the first week of posters here:
https://securix.app/awareness?utm_source=devto&utm_medium=social&utm_campaign=awareness_week1

Securing the Agentic Era: Building an MCP Middleware Layer

Subramanyan Balakrishnan — Fri, 24 Apr 2026 13:10:38 +0000

If you’ve been building in the AI space recently, you’ve probably played around with the Model Context Protocol (MCP). It is a massive step forward in standardizing how LLMs interact with external tools and data.

But as we transition from chatbots to fully autonomous agentic workflows—where agents take actions inside CRMs, databases, and production environments—a glaring problem is emerging: Trust.

Right now, connecting an agent directly to your tools often grants it "God Mode."

If you give an LLM direct access to an enterprise API, how do you prevent it from dropping a table, emailing the wrong client, or exposing PII in its context window? You can't rely on the LLM to govern itself via prompt engineering.

The "What": Enter the Agent Access Security Broker (AASB)
We realized that agents need the equivalent of an API Gateway or a Cloud Access Security Broker (CASB). We call this an Agent Access Security Broker (AASB).

SecuriX is built to sit directly between the AI Agent and the Enterprise/Private Data. It acts as a "Secure MCP" middleware layer.

Instead of your agent talking to your database, it talks to SecuriX. SecuriX then executes the action based on strict policies.

Building the Trust Layer in Public
The transition to the Agentic Era won't happen until enterprise security teams trust the infrastructure. We are currently building this AASB category out in the open.

If you are dealing with these MCP limitations, trying to secure your agentic workflows, or just interested in the architecture behind AI security, I am documenting the entire journey, the technical hurdles, and the solutions in a daily series.

You can follow along and read the technical deep-dives here: #30DaysOfTrust - Building the Agent Access Security Broker

I’d love to hear from other devs building agentic tools.

Building autonomous AI agents is fun. Securing their access in production is a nightmare.

Subramanyan Balakrishnan — Wed, 08 Apr 2026 12:53:15 +0000

Hey DEV community! 👋

If you’ve been spending your time building multi-agent systems, you already know the reality: getting the agent to reason correctly is the fun part.

But the moment you try to deploy that agent for enterprise clients? You hit a brick wall.

Suddenly, you're spending 80% of your sprint dealing with custom OAuth vaulting, managing connection lifecycles, and trying to prove to a B2B client's CISO that your agent won't accidentally leak data or perform unauthorized actions.

My co-founder and I got tired of this deployment friction, so we built SecuriX—an Agent Access Security Broker (AASB). The core philosophy is simple: we completely decouple your agent's application logic from its security and access layer.

How we're solving this 🛠️
We designed SecuriX strictly as a B2B infrastructure tool for developers. We don't interact with your end-users; we just give you the leverage to build secure agents faster without changing your database schema.

Here is what the developer experience actually looks like in a Next.js environment:

The Frontend (The Magic Button) Drop in our React component to handle the entire OAuth handshake securely.

TypeScript
"use client";
import { SecurixButton } from "@securix/client";

export function ConnectComponent() {
  return (
    <SecurixButton
      entityId="user_123"
      providers={{
        gmail: { scopes: ["https://www.googleapis.com/auth/gmail.readonly"] },
      }}
      onResult={(success) => {
        if (success) console.log("Handshake complete.");
      }}
    >
      Connect Gmail
    </SecurixButton>
  );
}

The Backend (One-Line API Handler) Handle all callbacks and token routing with a single dynamic route in your Next.js app.

TypeScript
// app/api/securix/[[...path]]/route.ts
import { toNextJsHandler } from "@securix/core";

export const { GET, POST } = toNextJsHandler;

Data Access (The Proxy Approach) When your agent actually needs to fetch data, you just point the standard SDK (like Google's) to our proxy URL. We inject the vaulting context on the fly—no need to retrieve or manage access tokens yourself.

TypeScript
import { google } from "googleapis";

export async function listEmails(entityId: string) {
  const gmail = google.gmail({
    version: "v1",
    rootUrl: "https://gmail.api.securix.app",
    headers: {
      "securix-api-key": process.env.SECURIX_API_KEY,
      "securix-entity-id": entityId,
    },
  });

  const response = await gmail.users.messages.list({ userId: "me" });
  return response.data;
}

Beyond the Code: The Trust Layer & Policy Console
Getting the connection is only half the battle. SecuriX also provides:

Policy as Code: Set context-aware restrictions instantly (e.g., force draft-only mode, or hard-block interactions with @bank.com).

White-Labeled Trust Portal: Give your enterprise clients a deployable security portal on your own domain (e.g., security.yourstartup.com). Your SaaS clients get real-time activity logs, granular permission controls, and a single Kill Switch to revoke agent access immediately.

We need you to stress-test it 🐛
We are currently refining our architecture and gearing up to pitch at the IITM Incubation Cell. But before we finalize things, we need real developers building real agentic workflows to break our SDK and give us raw feedback.

We are looking for our first cohort of Design Partners.

What’s in it for you?

Free, white-glove onboarding and early access to our portals/SDK.

The ability to dictate our engineering roadmap. If you have a specific integration headache or a unique policy requirement, tell us, and we will build it for you.

The chance to offload your agent security so you can get back to building the actual AI logic.

If you're actively building AI agents and want to stop worrying about auth and security, drop a comment below or send me a message. I’d love to get you access, show you the docs, and hear your honest thoughts!

The "God Mode" Problem with AI Agents (and why standard OAuth isn't enough)

Subramanyan Balakrishnan — Fri, 03 Apr 2026 10:54:45 +0000

We are hitting a wall in the AI agent ecosystem, and it isn’t about reasoning capabilities or context windows. It’s an infrastructure problem.

Right now, the mass adoption of autonomous AI agents is stalled by a single, critical bottleneck: "God Mode" access.

As developers, we want to build agents that can interact with the real world—read emails, summarize docs, create calendar invites. But the moment we try to connect an agent to user data, we run headfirst into the limitations of standard OAuth.

The All-or-Nothing Trap
Take a simple Gmail integration as an example.

Let's say you are building an agent whose only job is to draft email replies based on a user's calendar. To allow the agent to write a draft via the Gmail API, standard OAuth forces you to request scopes that also grant the permission to Send emails.

You are forced to ask the user for the keys to the kingdom just to let an agent write a draft.

Unsurprisingly, end-users are terrified to hand over unrestricted access to autonomous systems. One prompt injection or hallucination, and the agent could email the entire company.

The Developer's Dilemma
Because OAuth lacks granular, context-aware boundaries for AI, the burden falls entirely on us.

To make agents safe for enterprise or serious consumer use, developers are wasting months of engineering time building custom, SOC2-compliant data ingestion pipelines and proxy layers. Instead of focusing on core agent logic, we are building complex middleware just to stop an agent from going rogue.

How is the industry solving this?
My team and I have been obsessed with this problem. We came to the conclusion that we need a new infrastructure layer—an Agent Access Security Broker (AASB)—to sit between autonomous agents and user data as a real-time, context-aware proxy. We are building one from the ground up to give developers out-of-the-box granular control (e.g., enforcing a strict "Draft-Only" policy at the proxy level, regardless of the OAuth scope).

But I want to know how the rest of the community is handling this right now.

If you are building multi-agent systems that touch sensitive user data:

How are you restricting agent actions? Are you rolling your own proxy servers? Relying on system prompts (which feel risky)?

Are you utilizing the Model Context Protocol (MCP) to handle secure boundaries?

How do you handle the UX of trust? How do you convince your users that your agent won't accidentally delete their database or send a rogue email?

Would love to hear about the architectures and workarounds you are all using to keep agents sandboxed.