Manav vs DIY agent auth
We've never met an internal agent-auth project that survived its second audit. Build is tempting; the cost curve is brutal. Here is the math.
Why teams build it
"We have OAuth. We have an IDP. We have crypto engineers. How hard can it be?" The instinct is reasonable: most agent-auth projects start as a simple wrapper — sign a JWT, attach to MCP tool calls, log it somewhere. A junior engineer ships v1 in a sprint. The team feels good.
Where it falls apart
Six predictable break-points, in order of when they hit:
Month 2 — key rotation. Tokens are signed with the team's private key. The key needs to rotate. Now you need a key registry, distribution, and grace-period logic. None of these were in v1.
Month 3 — multi-tenant. The first customer who is not your company arrives. Your tokens are signed under your trust root; you have no path to issue customer-tenant tokens without inventing a federation layer.
Month 4 — revocation latency. An incident. The agent is loose. Revocation requires every relying party to check a list before accepting. Your reference list is a database. Distribution latency is minutes. The incident response plan is a Slack channel.
Month 5 — scope language. Customers want narrower scopes. You wrote scopes as strings. Each new permission shape needs a code change. Backwards compatibility is now a gauntlet.
Month 6 — the audit. SOC 2 or ISO 42001 auditor arrives. Asks for the four anchors: identity, authority, action, audit. Your audit log is JSON in S3. There is no tamper-evidence. The auditor flags it. You start building Merkle trees.
Month 9 — Article 14. The EU AI Act is now enforced. The two-natural-person rule for critical systems requires you to bind to verified humans, not service accounts. Your DIY system was built around service accounts. You start over on the human-binding layer.
The hidden cost
| DIY | Manav | |
|---|---|---|
| Initial build | 2 engineers, 6 months | 2 weeks integration |
| Ongoing maintenance | 0.5 FTE permanent | SLA-bounded |
| Standards drift | Your problem | Vendor's problem |
| Audit-readiness | 3-month project per audit | Pre-built artifacts |
| Customer trust | Hard to assert | Open-source, audited |
| Article 14 fit | Build-it-yourself | Native primitive |
| 5-year TCO (mid-size) | ~$2.4M | ~$0.6M |
When DIY is correct
Three honest cases. (1) You are an identity company. Your moat is owning these primitives. Build. (2) You have unusual constraints — air-gapped environments, sovereign requirements, latency profiles standard products don't meet. Build, with eyes open. (3) Your AI footprint is genuinely small and you do not need Article 14 compliance. The math doesn't apply.
When buying is correct
Everyone else. Especially: regulated industries with audit obligations, multi-tenant SaaS, cross-cloud agent fleets, anything sold into the EU after today. The category is being built; participating in someone else's category is cheaper than founding your own version of it.
Common objections
Buyers reasonably ask: do we have to choose? No. Most production stacks run both — the incumbent for the layer it owns, the new category for the layer the incumbent does not. The category split is real; the integration is clean; the procurement question is sequencing, not selection.
Frequently asked questions
Why not just use the incumbent for both? Because the incumbent was built for the previous problem. The fact that the workflow looks similar masks an architectural mismatch the incumbent cannot fix without rebuilding. We respect the incumbent; we do not pretend they ship the answer.
Where does the incumbent still win? In its native category. Use the incumbent where it was designed to operate; use the new layer where the new category begins. Most production stacks end up running both, with a clean handoff between them.
How long until we have to choose? You don't, mostly. The clean integration runs both side-by-side. The choice arrives only when a procurement contract forces consolidation, and by then the data on which layer is doing the work is usually clear.
Where to start
To go deeper, read best agent identity 2026 for the architectural diff and ai act article 14 playbook for the broader vendor map. Most procurement teams converge on the same composition — incumbent plus the new layer — once they have walked both.
What it actually costs to build this in-house
A senior engineering organization can build a credential issuer, a delegation token format, and a verification path in about six months. What they cannot build in six months is the legal interpretation work — twelve regulatory regimes, forty-three relying-party policy positions, ninety-one audit-grade evidence templates — and the trust-network work — the BBS+ cryptographic library, the issuer registry, the witness federation, the catastrophic-loss recovery process. Those take years and a dedicated team. The DIY math we see most often pencils out at $4–6M annual run-rate for a credible in-house build, plus a permanent dependency on a security team that does nothing else. The Manav contract is a fraction of that and rises only with usage. The DIY decision makes sense only when the buyer has unique compliance requirements no vendor can address, which in our experience is roughly one in fifty conversations. The other forty-nine should buy.
Build-vs-buy is rarely a question of capability. It's a question of who pays the maintenance bill in year three.