MCP hackathon results show secure identity is now agent infrastructure

At a glance

What this is: Descope’s hackathon results show MCP servers and AI agents becoming identity-governed execution surfaces, not just integration experiments.

Why it matters: IAM, PAM, and NHI teams should read this as a signal that agent authentication, delegation, and permission scope now need design-time governance, not ad hoc treatment.

Context

MCP servers turn tools and APIs into something an agent can call, which means the security question is no longer just whether a service exists, but what identity is allowed to invoke it and under what scope. In this hackathon, the primary pattern was secure access design for AI agents and MCP-backed workflows, not simple automation.

That shifts the governance problem into NHI and agentic identity territory. If agents can authenticate, delegate, and act across Google Sheets, Slack, GitHub, healthcare workflows, or security operations, then lifecycle, consent, and authorization boundaries become part of the production architecture, not a later control layer.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do scoped tokens matter for agentic workflows?

A: Scoped tokens matter because agents act at runtime and may reach multiple systems through one delegated path. Narrow scoping limits the blast radius if an agent misbehaves, is over-tasked, or is reused in a new context. Broad or shared credentials collapse accountability and make revocation far harder.

Q: What breaks when an agent identity is reused across multiple workflows?

A: Reused identities collapse separation of purpose and widen blast radius. Audit logs become harder to interpret, revocation becomes ambiguous, and one workflow can inherit trust that belonged to another. A reusable agent identity should be the exception, not the default, because it weakens both accountability and containment.

Q: How do teams know if agent access is staying inside its intended scope?

A: Measure execution-level evidence, not just identity events. Look for tool calls, resource access, action sequences, and revocation behaviour tied to a specific task. If the only evidence is authentication and token issuance, you do not have enough signal to judge scope adherence.

Technical breakdown

MCP servers as agent-accessible control surfaces

Model Context Protocol, or MCP, exposes external tools in a way that an AI agent can call at runtime. In practice, that turns ordinary SaaS functions and APIs into governed execution surfaces. The security distinction matters because the agent is not just reading data. It is invoking actions through a credentialed path, often across multiple systems. That means the real control problem is not the API alone, but the identity relationship between the agent, the tool, and the permission boundary that limits what the agent can do once connected.

Practical implication: treat every MCP endpoint as an identity-controlled action surface and define scope before the agent is allowed to call it.

Scoped tokens and delegated consent for agent workflows

The hackathon projects relied on scoped JWTs, OAuth-based authentication, and outbound app patterns so agents could act without hardcoded tokens or custom auth logic. That is the right architectural direction because agentic systems need constrained delegation, not shared secrets copied into prompts or code. The important point is that delegated access must remain task-scoped and revocable. If the token can reach more systems than the agent needs, the identity model is already too broad, even if the workflow feels convenient.

Practical implication: replace shared or embedded credentials with narrowly scoped delegated access that can be revoked per workflow and per agent.

Multi-agent orchestration changes the privilege model

Several submissions used multiple specialised agents coordinated by an orchestrator, with some systems even feeding back test results to trigger further actions. That pattern introduces a different risk profile from a single bot calling a single API. Privilege is now distributed across roles such as planner, executor, reviewer, and responder. Each role needs its own identity boundary, because an orchestrator that can route tasks can also amplify mistakes. The issue is not simply automation scale; it is that the trust decision moves from one actor to a chain of actors.

Practical implication: separate identities for orchestrator and sub-agents, and review privilege by role rather than by project or team name.

NHI Mgmt Group analysis

Identity is now the control plane for agent execution: Once an agent can authenticate and invoke tools, the security boundary moves from the prompt to the permission model. The hackathon entries show that useful agent systems are built on scoped delegation, revocable access, and explicit tool boundaries. That makes identity design an execution requirement, not a separate governance discussion.

Scoped delegation is a governance pattern, not a convenience feature: The strongest submissions avoided hardcoded tokens and custom OAuth plumbing because those shortcuts collapse accountability. When an agent can act across Slack, GitHub, Sheets, or healthcare workflows, the question becomes whether each action is narrowly attributable and removable. Practitioners should treat delegation scope as a policy object, not a development detail.

Agent orchestration creates identity blast radius: Multi-agent systems distribute trust across planners, executors, and reviewers, which means one weak identity control can multiply across the chain. That pattern is especially important for security operations and software creation use cases, where an orchestrator can turn a narrow request into many downstream actions. The practical implication is that role separation must be enforced at the identity layer, not only in workflow logic.

Autonomous action collapses the assumption that access is static long enough to be reviewed: Access review was designed for privileges that persist between governance cycles. That assumption fails when agents acquire, use, and discard access inside a live workflow because there may be no stable access state to certify later. The implication is not merely better review cadence, but a rethink of where control is enforced in the lifecycle.

Named concept: agent identity control plane: This article shows a pattern where identity becomes the primary control plane for AI systems that can call tools, delegate work, and modify external systems. That concept matters because the governance problem is no longer whether an AI exists, but whether its identity, scope, and revocation model are fit for runtime action. Practitioners should design agent identity as production infrastructure from the outset.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agent identity control plane: The practical shift here is that identity becomes the runtime control plane for tool use, not a background access record. That means teams need to decide where agent authentication ends and delegated execution begins, especially when MCP servers expose operational systems.

Security programmes that already struggle with service account sprawl should expect the same pattern to reappear in agent form, only faster. The governance gap is not agent intelligence, it is the absence of a lifecycle model that treats tool-calling identities as production assets with scope and revocation requirements.

For practitioners

• Define agent identity boundaries before tool access Map every agent to a specific role, permitted tool set, and revocation path before it can call any MCP server or outbound app.
• Replace embedded credentials with scoped delegation Use scoped tokens and OAuth-based flows instead of hardcoded secrets so each workflow has a distinct, revocable authorization path.
• Separate orchestrator and sub-agent privileges Give planner, executor, and reviewer agents different identities so one compromised or overreaching component cannot inherit the whole workflow.
• Log agent actions at the identity layer Record which agent identity invoked which tool, with what scope, and on behalf of which task so later audit does not rely on prompt reconstruction.

Key takeaways

• MCP changes the security question from whether a tool is exposed to which identity is allowed to invoke it and under what scope.
• The hackathon results show that scoped delegation, not hardcoded tokens, is the control pattern that makes agent workflows governable.
• Multi-agent systems increase identity blast radius, so orchestrator and sub-agent privileges should be separated and audited independently.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Scoped Delegation: Scoped delegation is the practice of giving an agent time-bound authority limited to a specific task, resource, or condition. It prevents inherited access from becoming permanent and preserves accountability by recording who granted authority, what was granted, and when it expires.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or NHI programme, it is worth exploring.