MCP hackathon results show secure identity is now agent infrastructure

At a glance

What this is: This is Descope’s recap of its Global MCP Hackathon, highlighting how teams built secure AI agents and MCP servers around authentication, delegation, and scoped access.

Why it matters: It matters because the patterns on display map directly to how IAM, NHI, and agentic AI governance will have to coexist when autonomous software starts calling real tools.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Descope's recap of the Global MCP Hackathon winners and secure agent patterns

Context

MCP makes AI agents useful by giving them a standard way to call tools and data sources, but that usefulness immediately creates identity questions. Once agents can authenticate, hold scoped tokens, and invoke actions across systems, the real governance problem shifts from interface design to who or what is allowed to act, under what delegation model, and with what audit trail.

This hackathon is a useful signal because it places identity at the center of agent workflows rather than at the edge. The strongest submissions did not treat authentication as a bolt-on feature. They treated identity as the mechanism that made autonomous software safe enough to use in real business processes.

Key questions

Q: How should security teams govern AI agents that use MCP to access business tools?

A: Start by treating each agent as a distinct identity subject with its own credentials, scope, and logging. Do not rely on a shared integration token or a generic service account. The control goal is to preserve attribution and contain blast radius when agents call tools across Slack, GitHub, calendars, or internal APIs.

Q: Why do agent-to-agent workflows create more risk than single-agent automation?

A: Because each handoff creates another delegation decision, another credential boundary, and another opportunity for scope to widen. Once one agent can route work to another, the security model has to prove that no step inherits authority that the previous step did not legitimately need. That is harder than traditional automation.

Q: What do security teams get wrong about secure MCP servers?

A: They often focus on the transport or API wrapper and miss the identity policy underneath it. A secure MCP server must prove who invoked the tool, what scope was granted, and how the action was recorded. Without that, the server is just a convenient way to move uncontrolled access around the estate.

Q: How do IAM and NHI teams decide whether an agent integration is safe enough to deploy?

A: Use the same questions you would use for high-risk non-human access: who owns it, what it can reach, how long the credential lasts, and whether every action is auditable. If the answer is unclear at any of those points, the integration is not ready for production use.

Technical breakdown

How MCP changes the identity boundary for AI agents

MCP gives AI systems a standard interface to tools, but the protocol itself does not create trust. Trust still comes from the identity layer, which now has to issue, scope, and audit credentials for software that can choose actions at runtime. In practice, that means an agent is no longer just a client calling an API. It becomes an active identity subject that can carry delegated authority across multiple services, which makes token scope, consent, and logging materially more important than in conventional automation.

Practical implication: treat MCP enablement as an identity design exercise, not a developer convenience layer.

Why scoped tokens matter more in agent-to-agent systems

The hackathon examples show a shift from single-session access to chained delegation. When one agent routes work to another, every hop becomes a trust decision that can widen blast radius if scopes are too broad. Scoped JWTs, outbound apps, and per-agent credentials are all attempts to keep delegation legible. The architectural issue is not whether agents can share work, but whether each exchange is constrained enough that one compromised step cannot silently inherit the whole environment.

Practical implication: design each agent hop with separate scope, expiry, and auditability instead of reusing broad shared credentials.

Why Zero Trust and auditability become non-negotiable for MCP servers

A secure MCP server is not just an API wrapper. It is a policy enforcement point for machine identities, because agents may read, write, and coordinate across systems in ways that humans never directly observe. That makes continuous verification and traceable actions central to the architecture. If the server cannot show which identity invoked which tool, with what consent, and for what bounded purpose, then the server is operating as an ungoverned access broker rather than a controlled identity plane.

Practical implication: require per-action logging, policy checks, and reviewable consent records before exposing any MCP server to production agents.

Threat narrative

Attacker objective: The objective is to turn delegated machine access into broad, hard-to-audit control over enterprise workflows and data.

1. Entry occurs when an AI agent or MCP server receives delegated access to tools such as GitHub, Slack, Google Calendar, or spreadsheets through authenticated connections.
2. Escalation happens when that delegated access is too broad, allowing the agent to chain actions across systems or reuse credentials beyond the original purpose.
3. Impact is created when an agent can read, write, or coordinate across business systems without strong scoping, enabling data leakage, unauthorized changes, or opaque automation at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is becoming the control plane for agentic software, not just a support layer. The hackathon winners show that once AI agents can authenticate to real tools, the security question is no longer whether automation exists, but which identity is carrying the authority. That shifts governance from application permissions to delegated machine authority, which is where IAM, NHI, and agent oversight converge. Practitioners should now treat every agent integration as an identity programme decision, not a feature toggle.

Scoped delegation is the difference between useful agent workflows and ungoverned tool sprawl. The strongest patterns in the post relied on per-agent identity, bounded JWTs, and explicit permission paths because broad shared credentials would have made the same workflows unsafe. This is the same lesson NHI teams learned with service accounts, now repeated at higher speed by agentic software. The implication is that access design must be specific enough to preserve accountability at each delegation step.

Shared credentials are a poor fit for MCP-era systems because they hide which actor actually performed the action. When multiple agents, tools, and orchestrators participate in one workflow, accountability depends on identity boundaries remaining visible. If those boundaries collapse into one generic token or service principal, incident review becomes guesswork. Practitioners should assume that the future failure mode is not lack of automation, but excessive delegation without identity separation.

Runtime identity governance is now the named concept practitioners need to track. Agentic systems do not merely consume credentials, they use them dynamically across tool chains that can expand during execution. That creates a governance gap between issued authority and observable use, which is why static provisioning logic is insufficient on its own. The practical conclusion is that identity policy has to follow runtime behaviour, not just initial enrolment.

MCP adoption will accelerate pressure on IAM teams to unify human, NHI, and agent governance models. The hackathon demonstrates that the same pattern can touch developer workflows, enterprise security, and digital identity verification. That means policy vocabulary, audit expectations, and lifecycle controls can no longer be separate by actor type. Practitioners should prepare for one governance model that can explain all three.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap is why OWASP Agentic Applications Top 10 is becoming a practical reference point for runtime identity governance.

What this signals

Runtime identity governance will become the practical test for whether MCP deployments are safe to scale. The organisations that can separate orchestrator authority from worker authority will have a far easier path to auditability than those that continue to treat agent access as if it were ordinary API integration.

The governance gap is already visible in market data: 80% of organisations report AI agents have acted beyond intended scope, which means agent identity cannot be managed as a static provisioning problem. That pattern pushes IAM teams toward tighter consent, shorter-lived credentials, and more explicit approval boundaries for machine actors.

Teams should also expect the policy conversation to converge across human, NHI, and agent programmes. Once agents are calling real business systems, the control questions become the same ones that matter for service accounts and privileged workflows: who approved the access, how it is constrained, and how it is revoked when the task ends.

For practitioners

• Define per-agent identities before production rollout Issue each agent its own identity, token, and audit trail so actions can be attributed to a specific runtime actor instead of a shared integration account.
• Bound every delegated tool call by scope and expiry Use short-lived credentials, narrow scopes, and explicit consent paths for each tool interaction so a single permission grant does not become environment-wide access.
• Log tool invocation context end to end Capture which identity called which tool, what data was accessed, and what action was taken so review teams can reconstruct agent behaviour without ambiguity.
• Separate orchestrator authority from worker authority Keep the agent that routes tasks distinct from the agents that execute them, and do not let the router inherit blanket write access to downstream systems.

Key takeaways

• MCP makes identity the primary security boundary for AI agents because tool access is only as safe as the delegated credentials behind it.
• Scoped tokens, per-agent identities, and end-to-end auditability are the controls that separate useful agent automation from uncontrolled delegation.
• IAM, NHI, and agent governance are converging, so practitioners need one runtime model that explains who can act, what they can reach, and how actions are proven.

Key terms

• Mcp Server: An MCP server is a tool-access layer that exposes applications and APIs to AI systems through a standard protocol. In practice, it becomes an identity enforcement point because the server must decide which agent can call which tool, under what scope, and with what audit trail.
• Scoped Delegation: Scoped delegation is the practice of granting a non-human actor only the exact authority it needs for a specific task. For AI agents and workflows, the key issue is that the scope must remain visible, time-bounded, and attributable across every downstream action.
• Runtime Identity Governance: Runtime identity governance is the control discipline that evaluates what an actor actually does while a session is live, not only what it was allowed to do at provisioning time. For agents, this matters because behaviour can expand across tools and systems during execution.
• Agent-to-Agent Trust Boundary: An agent-to-agent trust boundary is the point where one software actor hands authority, data, or decisions to another. It is a governance boundary, not just a technical integration point, because each handoff can widen blast radius if identity, scope, and logging are weak.

What's in the full analysis

Descope's full blog post covers the implementation detail this post intentionally leaves for the source:

• How the hackathon teams wired Descope Outbound Apps and Inbound Apps into real MCP workflows.
• The specific app-by-app integration patterns used for GitHub, Slack, Google Calendar, and spreadsheet access.
• How the winning teams structured agent identities, scoped JWTs, and delegated consent in practice.
• The sponsor and judge context behind the event, including the developer tooling used across submissions.

👉 Descope's full post includes the winning builds, the MCP server challenge entries, and the identity patterns behind each project.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.