Saurabh Singh
All consulting services

Consulting · AI & agent infrastructure

Put agents into production without handing them your blast radius.

The model is rarely the hard part. The hard part is that an agent calling a tool is a distributed system with an unusual property: it decides at runtime what to do next. That turns ordinary questions — whose permissions apply, which version of a decision is current, what happens when it is confidently wrong — into architecture problems. I work on that layer, not on prompt tuning.

01Who this is for

Where this work fits

You might recognize

  • Teams exposing internal tools or APIs to agents over MCP who have not settled whose identity the tool call carries.
  • Platform teams asked to let agents act on production systems, where "it worked in the demo" is not sufficient evidence.
  • Engineering groups whose coding agents confidently contradict decisions the team already made.
  • Teams using LLMs for operational triage who need the output to be reviewable rather than authoritative.

What it costs you

  • An agent acting with a service account's permissions can do anything that account can, with no user-level audit trail.
  • Bearer tokens forwarded between agent hops mean whoever holds the string is the caller, across trust boundaries nobody drew.
  • Agents retrieving by similarity surface superseded decisions with the same confidence as current ones.
  • Model output treated as fact propagates: one wrong inference becomes next week's assumed context.

02Approach

How the work runs

Identity first, then reach, then what the agent is trusted to remember. Each decision constrains the next.

  1. 01

    Decide whose identity the tool call carries

    User token, workload identity, both, or neither — each has a different failure mode. This choice constrains everything downstream, so it comes first.

  2. 02

    Bound what the agent can reach

    Audience-scoped tokens and workload identity, so a stolen credential is useful in one place rather than everywhere. Agents get the surface they need, not the surface that exists.

  3. 03

    Rank context by authority, not similarity

    Verified decisions should outrank inferred observations, and superseded knowledge should not win by default. Retrieval that ignores this is how agents contradict their own team.

  4. 04

    Keep inference out of canon until a human accepts it

    Agent-written notes are untrusted input. A review step before model output becomes institutional knowledge is the difference between memory and rumour.

  5. 05

    Make agent actions auditable

    Structured records of what was called, under whose authority, and on what basis — so incident response has something to read.

03Tradeoffs

What each choice costs

Every one of these has a downside. Here is what you are accepting and what you get for it.

  • Layered identity over one simple scheme

    More moving parts and more to operate. The alternative is a single credential whose compromise is indistinguishable from legitimate use.

  • A gateway over per-server auth logic

    A central policy plane becomes a dependency and a failure point needing its own capacity planning. With a handful of servers keep logic in the servers; with dozens or multiple tenants, the gateway earns its place.

  • Human review over fully autonomous memory

    Slower, and it needs someone to do the reviewing. It is also the only thing stopping a confident wrong inference from becoming permanent.

04Deliverables

What you get from a review

Scoped as a focused assessment. Anything beyond this is agreed before it starts, not assumed.

  • An identity model for agent tool calls: what each hop carries and what each service verifies.
  • A threat review of the current agent surface — what an agent can reach, and what a stolen token would unlock.
  • A context and retrieval design that ranks by authority and recency rather than similarity alone.
  • A human-in-the-loop boundary: where review is required before agent output is trusted.
  • A written assessment of which parts are worth building now and which are not yet worth the operational cost.

05Evidence

This is not theoretical

Where the work is still in development, it is labelled as such rather than presented as a delivered result.

Project · MemLore · in development

MemLore: Governed Context for Coding Agents over MCP

An engineering intelligence layer, in active development, that gives coding agents in Cursor, Claude Code, and Codex the team's current, evidenced decisions over MCP, instead of whatever text happens to be most similar.

See what it does

Technical write-up

Whose Identity Does the Tool See? Authenticating MCP in Production

Four ways to decide which identity sits behind an agent's tool call on Kubernetes, what each costs, and how to layer them.

Read the article

Technical write-up

MemLore vs SDD: When to Choose What

Why similarity search misleads coding agents, and what ranking context by authority and recency changes.

Read the article

Next step

Tell me what your agents are allowed to touch.

Which systems they reach, whose permissions they borrow, and what happens when one is confidently wrong. If the honest answer is that you are not ready to give agents production access yet, I will say that too.