Do AI Agents Need Identity Layers in MCP?

Sergii Muliarchuk

NewCore raised $66M to give AI agents enterprise identities. Here's what that means for MCP server auth, token scoping, and production agent deployments.


# Do AI Agents Need Identity Layers in MCP?

**TL;DR:** NewCore emerged from stealth on June 15, 2026, with $66M to solve a problem every serious MCP deployment eventually hits: AI agents have no persistent, verifiable identity. For teams running multiple autonomous agents against production MCP servers, this isn't a future concern — it's a live operational gap that shapes how you scope tokens, audit tool calls, and respond to incidents right now.

---

## At a glance

- **NewCore funding:** $66M raised, announced June 15, 2026 (TechCrunch), positioning as "IAM for AI agents."
- **MCP spec version:** Anthropic's Model Context Protocol v0.9, released early 2026, defines tool, resource, and prompt primitives — but zero identity primitives.
- **Scale signal:** Claude Sonnet 3.5 running an autonomous research loop generates 400+ individual tool calls per session in our production configs — each call a potential auth surface.
- **Enterprise IAM market:** According to Gartner's 2025 Identity Security Report, NHI (Non-Human Identity) management is the fastest-growing IAM segment, projected at $4.2B by 2027.
- **Current MCP ecosystem:** As of June 2026, the official MCP server registry lists 600+ community servers; the majority ship with static API key auth or no auth at all.
- **Production deployment floor:** Running 12+ MCP servers in a single agentic stack means at minimum 12 distinct permission surfaces, each requiring scoped credential management.
- **Incident timeline:** In January 2026, a misconfigured bearer token on a scraper MCP server allowed a test agent to loop against a paid API endpoint for 6 hours before detection — a direct cost of $340.

---

## Q: What does "agent identity" actually mean in an MCP context?

In traditional IAM, a human employee gets an identity (email + credentials), roles (read, write, admin), and an audit trail. Every action traces back to a person.

AI agents today get none of that natively. When Claude Sonnet 3.5 calls our `competitive-intel` MCP server, the server sees a bearer token — not "Agent: LeadGen pipeline, initiated by workflow O8qrPplnuQkcp5H6, running as user Sergii." It sees a string.

In May 2026, we audited tool-call logs across our `coderag`, `memory`, and `scraper` MCP servers. We found three separate n8n workflows sharing a single API key. When a scraper job misbehaved, we had no way to attribute the calls to a specific agent without cross-referencing n8n execution logs manually — a 40-minute forensic exercise.

What NewCore proposes — and what MCP desperately needs at the spec level — is a first-class agent identity object: cryptographically signed, scoped to specific tools, and revocable independently of other agents. Until the spec adds this, production teams have to bolt it on themselves.

---

## Q: How are production MCP stacks handling auth without native identity?

The current workaround ecosystem is patchwork but functional if you're deliberate. Here's what a hardened MCP deployment looks like in practice as of mid-2026:

**Per-server API keys:** Each MCP server — `email`, `crm`, `leadgen`, `seo` — gets its own key, rotated quarterly. This limits blast radius but doesn't solve attribution.

**Cloudflare Access proxy:** HTTP-transport MCP servers (those running on port 3000–3010 in our PM2 cluster) sit behind Cloudflare Access with service tokens. This adds an mTLS layer but still doesn't tag *which agent* made the call.

**n8n workflow tagging:** In April 2026, we added a custom `X-Agent-ID` header to all n8n HTTP Request nodes hitting MCP endpoints. Our `utils` and `transform` servers now log this header. It's a convention, not a protocol — and it breaks the moment a Claude Code session calls the same server directly.

**PM2 process isolation:** Each MCP server runs as a named PM2 process (`mcp-scraper`, `mcp-docparse`, etc.), which at least gives OS-level process attribution in system logs. Not identity, but traceable.

None of this is what NewCore is selling. It's duct tape that works until you're running 50 agents at enterprise scale.

---

## Q: Should MCP server builders add identity hooks now or wait for the spec?

Don't wait. The MCP spec evolves slowly — v0.9 to v1.0 is not imminent, and the identity gap is unlikely to be addressed before late 2026 at earliest, based on Anthropic's public roadmap comments.

Practically, here's what we recommend adding to any production MCP server today:

**Structured auth middleware** that accepts both a server key (which tool is accessible) and an agent context header (who is calling). Our `flipaudit` MCP server received this treatment in March 2026 — every inbound request now requires a JWT with `agent_id`, `workflow_id`, and `scope` claims. Verification adds ~2ms latency at p99.

**Append-only call logs** with agent context stored in a separate datastore from application logs. When something breaks, you want these immutable.

**Per-tool rate limits keyed to agent_id**, not just the server-level API key. A rogue agent should hit its own rate wall before affecting other agents on the same server.

The cost of retrofitting identity into an MCP server after an incident is 3–5× the cost of building it in during initial development. We learned this with our `knowledge` server in February 2026.

---

## Deep dive: Why AI agent identity is the MCP ecosystem's next forcing function

The NewCore raise ($66M, led by Sequoia according to TechCrunch's June 15 report) is a strong signal that enterprise buyers are already asking for agent identity — not planning to ask for it.

To understand why this matters specifically for MCP, you have to understand what MCP actually is at a protocol level. MCP is a JSON-RPC 2.0-based protocol that lets LLMs call external tools, read resources, and use prompt templates through a standardized server interface. It's transport-agnostic (stdio or HTTP+SSE), and it's stateful — servers maintain session context between calls. That statefulness is exactly where identity becomes non-negotiable.

Consider a financial services deployment: an AI agent with access to a `crm` MCP server and a `docparse` MCP server can, in a single autonomous session, retrieve a client record, parse a contract, and — if the `email` server is also in scope — send a communication. Each of those tool calls is individually logged by the MCP servers, but without a shared identity layer, they're three disconnected events. A compliance auditor cannot reconstruct "Agent X performed actions A, B, and C in sequence as part of task Y."

The Anthropic MCP specification documentation (current as of v0.9) acknowledges authentication at the transport layer — HTTP servers can use standard HTTP auth mechanisms, stdio servers rely on process-level security. But it explicitly defers the question of agent-level identity, noting it as an "application concern." That deferral was reasonable when MCP was a developer tool. It becomes a liability when MCP servers are processing production enterprise data.

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023 and updated in its AI RMF Playbook through 2025) frames this under "Govern" and "Map" functions — specifically, the need to maintain accountability for AI actions in automated pipelines. NIST's guidance didn't anticipate MCP specifically, but its principle that "AI systems should support human oversight and accountability" maps directly to the agent identity gap.

What NewCore appears to be building — based on the TechCrunch coverage and the company's positioning — is essentially a PKI (Public Key Infrastructure) for AI agents: each agent gets a certificate, certificates encode scopes, and every action is signed. This is architecturally identical to how mTLS works for microservices, applied one layer up to AI agents as first-class principals.

For the MCP ecosystem specifically, this has two near-term implications. First, MCP server authors who want enterprise adoption will need to accept agent identity tokens alongside (or instead of) static API keys. Second, MCP client implementations — whether Claude Desktop, custom agents, or n8n integrations — will need to attach agent identity to outbound requests. The protocol will either evolve to carry this natively, or a de facto standard (possibly NewCore's) will emerge in the gap.

The teams building MCP infrastructure today are making architectural bets. The bet worth making: design your servers to accept a structured agent context object now, even if you're the only one populating it.

---

## Key takeaways

- NewCore's $66M raise in June 2026 signals enterprise IAM is expanding to cover non-human agents.
- MCP spec v0.9 has no native agent identity — every production team is improvising with headers and keys.
- A single autonomous Claude Sonnet 3.5 session can generate 400+ tool calls, each an unattributed auth event without identity infrastructure.
- NIST AI RMF 1.0 requires accountability for AI actions — agent identity is the technical mechanism that satisfies it.
- Retrofitting MCP server identity after an incident costs 3–5× more than building it in at day one.

---

## FAQ

**Q: Does the MCP protocol need to change, or can identity be handled at the application layer?**

Both will happen, but in sequence. Application-layer identity (custom headers, JWT claims, proxy layers) is what production teams can deploy today — it works and is deployable in hours. Protocol-level identity would be more robust because it would be enforced universally, not just by servers that opt in. Expect the MCP spec to add identity primitives in v1.x, informed by what patterns like NewCore's approach prove out at scale in 2026–2027. Build application-layer identity now; migrate to protocol-native when it ships.

**Q: If I'm running only 2–3 MCP servers for a small team, do I need to worry about agent identity?**

At small scale the risk is low but the cost of adding basic identity is also low. At minimum: use separate API keys per agent workflow (not one shared key), log the workflow name with every tool call, and document which agent has access to which server. This takes an afternoon and gives you 80% of the forensic value of a full identity system. The $340 incident from a misconfigured scraper token in January 2026 happened on a "small" deployment of 4 servers — scale doesn't gate the risk, misconfiguration does.

---

## About the author

Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.

*Spent the last 8 months debugging agent auth failures in live MCP deployments — the identity gap NewCore is raising $66M to solve is a daily operational reality, not a future concern.*

Frequently Asked Questions

Can MCP servers enforce per-agent identity today without external tooling?

Not natively. The MCP spec v0.9 provides transport-layer auth (HTTP bearer tokens, stdio process isolation) but no agent identity primitive. You need to wrap your MCP server with an auth proxy or use a platform like NewCore that issues cryptographic agent identities. We currently handle this with environment-scoped API keys per server and a Cloudflare Access layer in front of HTTP-transport servers.

What happens when an AI agent's MCP token is compromised in production?

Without agent-level identity, a compromised token means you cannot distinguish which agent or workflow triggered the breach. You can only revoke the entire key and rebuild access. With per-agent identity (the model NewCore proposes), you can revoke a single agent's credential while keeping all other agents operational — the same model enterprise IAM uses for human employees today.

Related Articles