Side by Side
At a Glance
14 dimensions of comparison between Naftiko and Barndoor — same row, different layer of the stack. Scan top-to-bottom to see where each product makes a different choice on the same axis.
Dimension
Naftiko
Barndoor
Category
Naftiko
Spec-driven integration platform
Barndoor
AI agent control plane
Origin
Naftiko
Kin Lane (API Evangelist) + Jerome Louvel (Restlet → Talend → Qlik), 2025
Barndoor
Oren Michels (Mashery founder), 2024
Primary primitive
Naftiko
Capability — consumes APIs and exposes REST/MCP/Skills/A2A
Barndoor
Agent — registered identity that calls MCP servers
Layer in the stack
Naftiko
Build-time + ship-time + runtime engine
Barndoor
Runtime gate + proxy in front of MCP servers
Core artifact
Naftiko
YAML capability spec (declarative)
Barndoor
Cerbos RBAC/ABAC policy (versioned)
Open source posture
Naftiko
Apache 2.0 Framework, free Fleet community edition, paid Standard / Enterprise
Barndoor
SaaS-first; trial free, Team $500/mo, Pro custom, Enterprise on-prem
Multi-protocol
Naftiko
REST + MCP + Skills + A2A (roadmap) — same capability, all protocols
Barndoor
MCP + SSE only
Governance scope
Naftiko
Design-time (Spectral lint), admission (Kyverno / OPA), runtime engine
Barndoor
Per-call action authorization at the proxy boundary
Discovery surface
Naftiko
Backstage capability catalog + scorecards
Barndoor
Agent registry + Shadow AI Discovery
Audit / observability
Naftiko
OpenTelemetry + Prometheus + structured logs
Barndoor
S3-compatible audit log export (gzipped JSONL)
Identity / OAuth
Naftiko
Runtime secret injection (env, ExternalSecrets); Keycloak / OpenFGA roadmap
Barndoor
Auth0 OAuth 2.0 with PKCE; OAuth connection broker for backend SaaS
Cost / FinOps
Naftiko
Cost-center labels propagated to K8s; Kubecost integration
Barndoor
Agent-seat-based pricing; no per-call meters published
Egress posture
Naftiko
Customer-controlled (runs in customer infrastructure)
Barndoor
5 shared static egress IPs (Pro+)
Founder framing
Naftiko
“Capability fleet” — many ships, one navy
Barndoor
“Control plane” — one gate, many agents
Common Ground
Where They Overlap
Both Naftiko and Barndoor bet on the layer above per-vendor MCPs. Here are the 8 concrete places where those bets actually meet — same problem, sometimes the same shape, increasingly the same conversation.
1
MCP is a first-class concept for both
Naftiko exposes MCP servers. Barndoor governs MCP servers. Both treat MCP as protocol-level (SSE, JSON-RPC 2.0, credential injection) rather than just ‘another API.’
2
Both register a governable entity per workflow
Naftiko registers Capabilities; Barndoor registers Agents. Either way, the entity is the unit that gets policy applied to it.
3
Both reject vendor MCPs as the right enterprise abstraction
Naftiko's wedge is ‘vendor MCPs are too generic for context-engineering.’ Barndoor's wedge is ‘OAuth login is not enough — you need per-action authorization.’
4
Both ship audit trails by design
Naftiko via OpenTelemetry events; Barndoor via S3-compatible JSONL export. Both expect the audit signal to feed downstream SIEMs and dashboards.
5
Both deal with credentials at runtime
Naftiko via runtime secret injection (env vars, ExternalSecrets); Barndoor via OAuth 2.0 brokering on behalf of agents.
6
Both ship enterprise deployment paths
Naftiko is self-hosted by default (open-source Framework + Kubernetes operator); Barndoor offers SaaS, private cloud, and on-prem.
7
Both have a discovery story for ‘what's running in my org’
Naftiko via Backstage capability catalog and dependency graph; Barndoor via agent registry and Shadow AI Discovery.
8
Both founders come from prior-generation API management
Mashery (Oren Michels) and Restlet (Jerome Louvel) — both shaped the API economy a decade before MCP existed.
Where We Diverge
How Naftiko Is Different
The clearest single-sentence difference: Naftiko builds and exposes MCP servers (and REST APIs and Skills) from existing APIs; Barndoor governs traffic to MCP servers that already exist.
1
Consume + transform + expose vs proxy + enforce
Naftiko
Take an existing API (Bloomberg AIM, GitHub, SAP) and ship it as a governed MCP server / REST API / Skill. Naftiko makes the artifact.
Barndoor
Sit in front of MCP servers and decide which agent calls go through. Barndoor gates traffic to artifacts that already exist.
2
Multi-protocol vs MCP-only exposure
Naftiko
A single capability serves REST (humans + tools), MCP (AI agents), Agent Skills (skill-bundle agents), and A2A (roadmap) from one YAML and one container.
Barndoor
Proxies MCP / SSE only. No REST or Skills surface for the same governed pathway.
3
Capabilities vs Agents as primary primitive
Naftiko
Primary identity is ‘the thing that does X’ — a functional unit composed from declared consumes and exposes.
Barndoor
Primary identity is ‘the agent that's calling’ — a registered caller identity with policies attached.
Different organizing primitives drive different governance shapes.
4
Three governance altitudes vs one
Naftiko
Spectral rulesets at design time, Kyverno / OPA at admission time, and runtime checks in the engine. Lifecycle-shaped governance.
Barndoor
Cerbos policies enforced at the moment of the call. Request-shaped governance only.
5
Open-source-first vs SaaS-first
Naftiko
Framework is Apache 2.0, intended to land in CNCF, with paid Fleet editions on top. Attracts platform engineers who self-host.
Barndoor
Auth0-rooted SaaS with paid tiers from $500/month and on-prem available. Attracts CISOs who want a procurement line item.
6
Consumes-side governance vs exposes-side only
Naftiko
Governs the consume side — HTTPS enforcement, PII detection on consumed APIs, credential governance, retry safety per upstream. Owns the supply chain.
Barndoor
Governs only what an agent is allowed to do with an MCP tool. Doesn't govern what's behind the tool. Owns the gate.
7
Ships Agent Skills as a first-class output vs not shipped
Naftiko
exposes: skill adapter ships an Agent Skills bundle alongside the same capability's MCP and REST surface.Barndoor
Governs MCP traffic but isn't a skill producer. The skill bundle has to come from somewhere else.
8
Per-call cost attribution vs per-seat ceiling
Naftiko
Cost-center labels propagate into Kubecost so per-call cost can be attributed to a tag, team, or capability.
Barndoor
Pricing is agent-seat-based with no per-call meters published.
Partnership Thesis
Service Partnership
Naftiko is build-and-ship. Barndoor is run-and-enforce. A Naftiko capability that builds an MCP server is the natural upstream artifact for a Barndoor policy that governs how agents use it. The capability map below is the integration kit that wires these two products together.
“Naftiko ships the MCP servers, REST APIs, and Agent Skills your enterprise needs. Barndoor enforces the per-call policy on every agent that uses them. Together: the build-and-govern stack for the AI integration era.”
Two First-Meeting Questions
Q1. Powered by Naftiko
Would Barndoor consider a ‘powered by Naftiko’ path for customers whose MCP servers don't yet exist — i.e., customers who need to build MCP servers from existing APIs before Barndoor can govern them? (Today Barndoor assumes MCP servers already exist.)
Q2. Barndoor as a Naftiko capability
Would Barndoor ship an MCP server for its own Platform API — so Naftiko (and other engines) can consume Barndoor as a capability the same way they consume any other governed service? The capability map below treats every Barndoor surface as a Naftiko-consumable one for exactly this reason.
Integration Kit
Partnership Capability Map
10 Naftiko capabilities authored to integrate with Barndoor as a service partner. Each one consumes a specific Barndoor surface and exposes it as REST + MCP through the Naftiko engine — shipped as inline alpha2 YAML in the api-evangelist repository and published to the apis.io capability catalog.
Barndoor Policy Sync
barndoor-policy-sync
Pull Barndoor RBAC/ABAC policies and revisions into Naftiko Fleet so every Naftiko-built MCP surfaces the matching Barndoor policy that governs its agent traffic.
Barndoor Policy as Code
barndoor-policy-as-code
Author Cerbos-style RBAC/ABAC policies in Barndoor through Naftiko's declarative spec layer. One spec, one deploy, two systems wired up.
Barndoor MCP Proxy Register
barndoor-mcp-proxy-register
Auto-register every Naftiko-built MCP server with Barndoor's MCP Servers Registry so Barndoor can govern agent traffic to it from day one.
Barndoor OAuth Broker
barndoor-oauth-broker
Route Naftiko consume-side OAuth handshakes through Barndoor's OAuth Connection Broker so the Naftiko engine never holds long-lived tokens.
Barndoor Agent Registry
barndoor-agent-registry
Surface Barndoor-registered agents (internal + external) into a Naftiko Fleet so Backstage's NaftikoFabricExplorerPage shows agents alongside Naftiko-built capabilities.
Barndoor Audit Stream
barndoor-audit-stream
Bridge Barndoor's S3-compatible audit log export into Naftiko's OpenTelemetry pipeline so a single Datadog / New Relic / Prometheus dashboard shows both systems.
Barndoor Egress Router
barndoor-egress-router
Route Naftiko consume-side outbound calls through Barndoor's static egress IPs so corporate firewalls and SaaS allow-lists work without per-customer egress infrastructure.
Barndoor Shadow AI Bridge
barndoor-shadow-ai-bridge
Pipe Barndoor's Shadow AI Discovery into Naftiko Signals as a 'shadow agents detected' signal on company landing pages — runtime evidence of unauthorized AI in the org.
Barndoor Policy Violation Webhook
barndoor-policy-violation-webhook
Bridge Barndoor policy-violation events into Naftiko's webhook-driven workflows — notify, escalate, throttle, or temporarily disable the offending capability.
Barndoor FinOps Bridge
barndoor-finops-bridge
Correlate Barndoor's per-agent seat metering with Naftiko's per-call cost attribution to produce a unified FOCUS-aligned cost view neither product can produce alone.
