Loading

Give AI agents real work, not unchecked power.

I build the control layer that decides what your AI agents are allowed to do in production, before they act.

Once an agent can issue a refund or message a customer, a prompt asking it to behave is not a control. I put the decision outside the model: every action is checked against policy before it runs, high-risk ones wait for a human, and all of it is logged. So you can ship agents into real operations and prove exactly what they can and cannot do.

Book a 30-minute call

No pitch. We pressure-test an agent you're building and whether it's safe to ship. You decide if a paid audit is worth it.

Scroll

▎A line in a prompt is a suggestion.

A model can be talked out of a suggestion. So the controls that stop a bad action live outside the model, not in the prompt.

Scoped access

Least-privilege by default.

Every agent only sees what it needs. Documented permission matrix. No high-risk action runs without approval.

Full audit trail

Every action logged.

Tool calls, inputs, outputs, approvers. Stored in your infrastructure. Exportable for compliance review.

Human in the loop

Approval gates on anything risky.

Customer-facing messages, writes to production, irreversible actions. Your team approves. Always.

▎What every agent I build will and won't do.

Will not autonomously
  • ✕Delete or permanently destroy data, files, repos, tickets, records, or accounts
  • ✕Send customer-facing messages (email, chat, SMS, support reply) without human approval
  • ✕Execute financial transactions (payments, refunds, transfers, contract signing)
  • ✕Write to production systems without scoped permissions and a rollback plan
  • ✕Access secrets or credentials except through approved vault patterns (1Password, Doppler, AWS Secrets Manager)
  • ✕Bypass existing approval workflows that humans rely on
  • ✕Take irreversible actions without a human-in-the-loop gate
  • ✕Use customer PII outside the boundaries set by your data classification
Every agent always has
  • ✓A documented permission matrix (who can do what)
  • ✓Scoped, least-privilege credentials for every tool it can reach
  • ✓Audit logs for every tool call (exportable, queryable)
  • ✓Human-approval gates on customer-facing or high-blast-radius actions
  • ✓Eval suite for known failure modes
  • ✓Rollback or undo plan for any state-changing operation
  • ✓A kill switch to disable any tool without a redeploy
  • ✓Failure-mode visibility (agent refuses unsafe requests and says why)

▎How an agent fits inside your infrastructure

~/agent-stack
$ describe-stack
LLM gatewayBifrostegress: client VPC only
OrchestratorMastraruns in client infra
ObservabilityLangfuseself-hosted, client owns data
Tool layercustom MCPleast-privilege scoped
Approval gatesSlack + webhooks
Audit sinkclient S3 / GCS
Eval suiteLangfuse + customcorrectness, PII, regression
Handoverrunbook + repoclient owns everything
$ describe-boundary
All components run inside client infrastructure.
No data leaves the boundary except via the LLM gateway.
Gateway logs every outbound call.
Every tool call is scoped, logged, and reversible.
$ status
ready.

▎Every outbound call is routed, logged, and governed by policy.

See it running: the governed agent demo
Offer

Agent Readiness Audit

$3,500/one week

I take an agent you're building or already running and pressure-test whether it's safe to put into production: what it can touch, what could go wrong, and what has to be true before your security team signs off. You get the gaps and the plan to close them. No commitment beyond the week.

What you get
  • →Action and access map: everything the agent can do and reach
  • →Blast-radius review: what breaks if it acts wrong, and where
  • →Permission matrix and data-classification draft
  • →Prioritized governance gaps with a plan to close each one
  • →30-minute readout call
Book a 30-minute callWe pressure-test one agent. You decide if a paid audit is worth it.

Who you're working with

I'm Sarthak, an engineer based in New Delhi. I build production AI agent systems for US tech companies, focused on the unglamorous parts most AI consultants skip: permissions, audit trails, evals, and rollback. If you can't show your security team how an agent works, you can't ship it.

For the last two years, I've worked on AI training and agent systems via Turing, IgniteTech, and G2i, on projects for OpenAI, Anthropic, Meta, and others. That work taught me what production-grade AI systems require beyond the demo. Now I'm bringing that into agent builds for US tech companies that need agents doing real work, with control over what they can do and proof of what they did.

▎Common questions

▸Isn't this just guardrails?
Guardrails put the safety in a prompt or a text filter, and a model can be talked out of a suggestion. This authorizes the agent's actions instead. The check runs outside the model, returns a deterministic allow or deny on the specific call and its inputs, and leaves a record. Guardrails are one layer. This is the layer that decides whether the action happens at all.
▸How is this different from AI agent security tools?
Most of them are runtime products that watch an agent, learn what looks normal, and flag or block what doesn't. That's probabilistic, and it's bolted on after the fact. I build the controls into the agent system itself: policy as code that returns a deterministic allow or deny on every action before it runs, plus the audit trail that proves what happened. You own it, it runs in your infrastructure, and it's built for the specific agent you're shipping, not a generic wrapper around it.
▸Why not just build this internally?
You can. The question is what your team's time is worth. Building a production agent system end-to-end (MCP servers, permissions, audit logs, evals, observability, integration with your existing tools) usually takes a senior engineer six to ten weeks of focused work. They have to learn the agent stack while building it. I've already done that learning on systems for OpenAI, Anthropic, Meta, and other frontier labs. Hire me for four weeks to ship a hardened pilot, or burn eight weeks of your engineer's time. Then your team owns and extends it.
▸Do you replace my security team?
No. I give them what they need to say yes. Most security teams don't want to block agents, they want to see what an agent can do, what it can't, and a record they can review. I build those controls and hand your team the permission matrix, the policies, and the audit trail. You keep the sign-off. I make it something you can actually sign off on.
▸What happens if you disappear?
Three things. One, you own all the code, the infrastructure, and the runbook. It lives in your accounts, not mine. Two, every engagement includes a handover doc that lets an internal engineer maintain and extend the system without me. Three, the architecture I build is intentionally boring. Standard tools (Mastra, Bifrost, Langfuse), standard patterns, no proprietary magic. If I disappeared tomorrow, your team could keep this running. That's a design constraint I impose on every project.

Map your highest-friction workflow.

One call. No pitch. You leave with a clearer picture of where agents will actually help.

Book a 30-minute call

Or reach me directly: sarthakgupta124@gmail.com