Infrastructure for agentic systems
The model stopped being the bottleneck a while ago. What stalls AI inside a company is that nobody will hand an autonomous process the keys to production, so the agent gets a sandbox, a stale export, and a demo that never ships.
Ikat is the control plane between your AI and your real systems. Scoped identity per agent, policy enforced in the path, a full record of every call, and the bill broken down by who spent it.
Early stage, built in the open. We are working with a handful of teams who already point agents at systems that would hurt to lose.
The gap
The pattern repeats in every company that has moved past the pilot. The AI is capable, the integration is trivial, and the thing standing in the way is that nobody can answer what it touched, on whose behalf, or what it cost.
Security is not being unreasonable. They just have no way to say yes.
Sources: Thomson Reuters Institute, shadow AI · State of Enterprise AI 2026 · LangChain, State of Agent Engineering · MarketScale, enterprise AI fault lines · Vantage, FinOps for token costs
Where we’re not building
We are a small studio in Chennai. Being clear about where we cannot win is the same discipline as being clear about where we can, so here is the map we drew before we picked anything.
| Territory | Already held by | Why we’re not there |
|---|---|---|
| Agent observability & evals | LangSmith, Braintrust, Arize, Langfuse, Datadog | Five well-funded platforms with converging feature sets, and the incumbent APM vendors moving in on top of them. The problem is real, the answer is being written, and a team our size would add nothing to it. |
| Portable AI memory | MemoryLake, MemoryBase, AI Context Flow | Mostly extension-shaped, sitting on surface area the model vendors can absorb into their own products at any time. We could not hold a position here long enough for it to matter. |
| Shadow-AI detection | Microsoft Entra, Wiz, Palo Alto Networks, BigID | This is a security-platform feature, and it is won on enterprise distribution rather than on engineering. The people who already sell the CASB and the CSPM will sell this in the same conversation. |
Detection tells you the AI touched something. It never tells the AI what it’s allowed to touch.
All three of those markets sit beside the request rather than inside it. They watch, score and report after the fact, which is the right shape for a problem you are trying to understand and the wrong shape for a decision you have to make on every single call.
The layer that has to be in the path, and that nobody has built for company scale yet, is the one that answers a much narrower question: this agent, this tool, these arguments, right now — yes or no, and on the record. That is the thing we are building.
What it does
Not a sequence of steps, and not a dashboard bolted on afterwards. All four run on the same round trip, before the call reaches anything real — which is the only moment where saying no still costs nothing.
Every agent, and every human it is acting for, gets a short-lived scoped credential. No agent ever holds a raw API key, and revoking one takes effect on the next call rather than the next deploy.
agent:support-triage
on-behalf-of: diva@
expires: 900s
Rules written as code: which agent may call which tool, with which arguments, against whose rows. A denial comes back with a reason the agent can act on, not a silent failure it will retry forever.
allow db.read
where tenant = caller.tenant
deny db.write
where table = "payments"
Tokens, tool calls and GPU-seconds attributed to a team, a feature, a customer, a single conversation. Budgets are enforced in the path, so a runaway loop stops instead of showing up on the invoice.
team:growth $1,284 +12%
agent:crawler $92 capped
One structured record per tool call, with the arguments, the decision and the result, streamed to the SIEM and APM you already run. When something goes wrong you replay the chain instead of guessing at it.
→ splunk · datadog · s3
replayable · signed · 400d
One round trip. Four answers: who asked, what they may touch, what it cost, and what actually happened.
How it works
Every request an agent makes crosses four planes before it reaches anything real. Most go straight through. Some do not — and the interesting part is what happens to those. Pick a call and follow it.
Two of those four planes are where the argument actually is.
The ledger runs before the spend, not after it. Cost is attributed while the call is still in the air rather than reconciled next month, so a team that is over budget stops at the gate instead of on the invoice. That is the difference between a bad afternoon and a bad quarter.
The trace is the receipt. When a call does go through, the whole decision — who asked, what they sent, what we said, and what came back — lands in the SIEM and APM you already run. Not one more dashboard somebody has to remember to open.
How it fits
Ikat talks MCP on both sides. Clients point at Ikat instead of at each server directly, and the servers you already run stay exactly as they are. It is one line of config, not a migration — and you can take it back out the same way.
# Who may do what. One file, checked into your repo,
# reviewed like any other code.
agent "support-triage" {
allow db.read where tenant == caller.tenant
allow search.web
deny db.write
}
agent "deploy-bot" {
allow db.migrate where env != "prod"
deny db.write where table == "payments"
} ↑ this is what refuses deploy-bot in the demo above
budget "growth" {
cap $90 / day
on_exceed deny
}// Any MCP client. One line changes: the endpoint.
{
"mcpServers": {
"company": {
- "url": "https://internal-tools.acme.dev/mcp",
+ "url": "https://ikat.acme.dev/mcp",
"headers": { "Authorization": "Bearer ${IKAT_TOKEN}" }
}
}
}
// Your servers stay where they are. Nothing in the agent
// code changes. Point it back and Ikat is out of the path.# One container, your network, your policy file.
docker run -p 8080:8080 \
-v ./policy.ikat:/etc/ikat/policy.ikat \
-e IKAT_TRACE_SINK="splunk://…" \
ghcr.io/ikat/gateway:latest
# No traffic leaves your network. The hosted version is
# a convenience, never a condition.The gateway and the policy engine are being built in the open. When Ikat refuses a call, you will be able to read the rule that refused it — and the code that evaluated the rule. None of it is published yet; this is the shape we are building to.
Who else is here
We are not the first people to notice that agents need a gateway. Every one of these is a real product built by people who know what they are doing, so the useful question is not who is better — it is what each of them optimised for, and what that left on the table.
The closest thing to a direct competitor, and genuinely open. An MCP gateway with auth and a server catalogue, wrapped inside a broader platform for building and running agents.
We are not selling a platform. Ikat is one layer you put in front of the agents and servers you already have, and it never asks you to build your agents our way.
The best answer to “how do I run and share MCP servers without trusting a stranger’s npm package”: signed catalogues, containerised servers, excellent local developer ergonomics.
That governs how servers are shipped. It does not answer which agent may call which tool, on whose behalf, against whose rows — the question that actually blocks the security review.
Enormous scale and effectively free. Caching, rate limiting, retries and analytics sitting in front of the model providers, on infrastructure nobody else can match.
It sits in front of the model. The thing that frightens your security team is not the completion — it is the tool call into Postgres, Stripe and GitHub. And it runs in their cloud; Ikat runs in yours.
Serious proxy engineering with a decade of Envoy behind it, and the right answer for an organisation that already runs a service mesh and has a platform team to operate it.
Ikat is a single binary that runs without adopting a mesh. It is shaped for the team with ten agents and no platform org, which is almost everyone right now.
The ledger is the part none of them put in the path.
Identity, policy and tracing are converging. Everyone on this list will have a credible version of all three within a year, and we are not going to win by claiming otherwise. What every one of them treats as a reporting problem is cost: a dashboard you read next month, after the money is gone.
In an agentic system that is the same problem twice. The runaway loop that burns nine thousand dollars is the runaway loop that hammered your production database, and both are decisions you can only make while the call is still in flight. Ikat makes them one decision, enforced in one place, on the record.
The name
ikat
/ˈiː.kɑːt/ EE-kaht
Malay, ikat — to tie, to bind
a resist-dye technique, c. 11th century
In ikat, the threads are bound and dyed before anything is woven. The pattern already exists in the thread while the cloth is still an intention. Every other patterned textile does the opposite: weave the cloth, then print the design onto the finished surface. That distinction is the entire product argument, which is why the name is the mechanism rather than a metaphor laid on top of it.
Not a metaphor we bolted on afterwards. The word is a verb, and it is the verb for what the product does: bind a credential to an agent, bind a policy to a call, bind a cost to a team.
Identity
Dye first, weave second. A policy that lives in the call before it executes is a different object from a rule reconstructed out of logs an hour later — the same way dyed thread is a different object from printed cloth.
Policy
Every call is a crossing of two threads: which agent, and which tool. Ikat is what sits at the crossing and decides. Everything else in this market sits politely beside it and takes notes.
Ledger
Real ikat has a feathered edge where warp and weft never quite align. It is how you tell a woven piece from a printed imitation — the honest record of how the thing was actually made.
Trace
Why now
Two years ago, every AI tool talked to your systems its own private way. Now they all speak one language — Model Context Protocol — and this year it moved under the Linux Foundation, which is the software world’s way of saying this is settled, you can build on it.
Wiring an agent into your production database is now about a five-minute job. That is the problem. A five-minute job just got the same reach as a senior engineer with a company laptop, and nobody agreed on who watches it, what it may touch, or who pays for what it burns.
The people writing the standard published a list of what is still missing. It reads like a job description for the thing we are building, and not one item on it needs a breakthrough — it needs somebody to sit down and build the unglamorous part properly.
Still missing, in their own words
How we build
Ikat sits in the path of your most sensitive traffic. That traffic should not have to leave your network for us to be useful, and the hosted version should be a convenience rather than a condition.
The gateway and the policy engine are open. If Ikat denies a call, you can read the rule that denied it and the code that evaluated the rule. Trust in this layer has to be verifiable.
This is a proxy in a hot path. It should be dull, fast and predictable under load, and it should fail in ways an on-call engineer can reason about at three in the morning.
One call we never deny
We are looking for a few teams to build this with. If you run agents against systems that matter, and you have already cobbled together your own answer to who-can-do-what, we want to see it. Tell us what you had to build before your security team would say yes.
Or come straight to me — I’m Divakaran, a backend engineer in Chennai (dhvakr.me) — LinkedInX
These rules are what the gateway evaluates on every call. Same file you would check into your repo.