By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: SemgrepPublished November 25, 2025

TL;DR: At an AWS AI Agents Hackathon, more than 250 developers built 50-plus projects around agentic workflows, with MCP, multi-LLM patterns, and in-browser security checks emerging as the dominant themes, according to Semgrep. The real issue is that faster agent-enabled development is expanding identity, tool, and trust boundaries before most governance models are ready.


At a glance

What this is: This is a Semgrep analysis of how developer teams are using MCP and AI agents in security-focused workflows, with the key finding that agentic development is moving toward integrated, pre-flight security controls.

Why it matters: It matters because AI agent workflows reshape how IAM, NHI, and security teams should think about tool access, trust decisions, and where to enforce controls before code or actions execute.

👉 Read Semgrep's analysis of MCP, agentic AI workflows, and secure development patterns


Context

MCP, or Model Context Protocol, is the interface layer that lets AI agents connect to tools, data sources, and development environments. In this article, the main governance question is not whether developers can move faster, but whether identity and control boundaries can keep up when agents are embedded directly into coding workflows.

That matters for NHI governance because developer environments increasingly include non-human identities such as tokens, service credentials, and agent connections that can be trusted too easily. Semgrep's event recap shows that the pressure to ship is pushing teams toward security checks earlier in the workflow, which is a familiar control problem in a new runtime context.


Key questions

Q: How should security teams design MCP server access for AI agents?

A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints. Group related backend calls into workflows, expose known data as resources, and reserve tools for actions that truly change state. That keeps the agent oriented, reduces context churn, and makes the access surface easier to review and govern.

Q: Why do AI coding agents create different governance risks from normal developer tools?

A: AI coding agents combine code execution, context persistence, external tool access, and memory across sessions. That makes them governed identity actors with a wider blast radius than a standard editor or plugin. The risk is not just what they generate, but what they can read, retain, and trigger on behalf of the developer.

Q: What do organisations get wrong about multi-LLM development workflows?

A: They often focus on choosing the best model and ignore where enforcement happens. Model selection affects quality, but policy enforcement, secret detection, and deterministic validation are what prevent unsafe output from becoming an operational security problem.

Q: How can teams reduce risk from malicious IDE extensions and MCP servers?

A: Use a third-party access model for plugins and servers, review the permissions they request, and revoke connections that no longer meet trust standards. The critical control is not convenience, it is limiting what untrusted tooling can reach inside the development environment.


Technical breakdown

MCP in agentic workflows

Model Context Protocol standardises how an AI agent can call tools, retrieve context, and interact with environments such as IDEs and security scanners. In practice, that means the agent does not merely generate text, it can trigger actions across connected systems once a tool is exposed through MCP. The security issue is that every new connection expands the agent's effective trust boundary, especially when developers connect external servers or internal services without a consistent vetting model. That makes MCP less like a convenience layer and more like an access control surface.

Practical implication: treat every MCP connection as an identity and authorisation decision, not a harmless plugin choice.

Multiple LLMs in one development workflow

Using more than one LLM in a workflow is becoming common because teams optimise for cost, privacy, speed, and code quality depending on the task. The architectural effect is that model selection becomes dynamic, and security outcomes depend on where deterministic checks are inserted, not just on which model produced the output. If one model generates risky patterns and another produces safer code, the control point is the evaluation layer, not the model brand. This is especially important when the workflow includes generated code that later inherits deployment credentials or access to production systems.

Practical implication: anchor decisions in deterministic validation, not model preference or output confidence.

Browser-based coding creates a shallow security boundary

Browser coding environments make it easier to create and test code quickly, but they often sit outside the deeper security integrations found in traditional IDEs. That creates a shallow inspection boundary where generated code can move forward before it has been scanned or checked against policy. In identity terms, this is where workflow convenience can outrun governance, because the toolchain accepts generated output before downstream controls have visibility. The result is not only a code-quality issue but a control-placement issue, since the earliest usable decision point may be inside the browser itself.

Practical implication: move security scanning into the browser workflow before generated code exits the session.


Threat narrative

Attacker objective: The objective is to reach developer-held secrets, manipulate code generation, or gain a foothold through trusted tooling in the software supply chain.

  1. Entry occurs when developers connect external MCP servers, IDE extensions, or browser-based AI tools into environments that already hold credentials and sensitive code.
  2. Escalation occurs when an unvetted tool can request access to files, secrets, or code paths that were not intended to be exposed to that session.
  3. Impact occurs when malicious or unsafe tooling reaches tokens, leaks sensitive material, or introduces vulnerable code into downstream development and deployment workflows.

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


NHI Mgmt Group analysis

MCP has become an access surface, not just an integration layer. Once agents can call tools through MCP, security teams are no longer governing simple content generation. They are governing delegated execution inside developer environments, which means trust decisions now attach to every server and tool exposure. The practical conclusion is that MCP needs the same scrutiny as any other privileged connectivity path.

Pre-flight inspection is the right control pattern for agentic development. The article shows teams moving security analysis earlier so generated code and external tool connections are checked before execution continues. That aligns with OWASP Agentic AI Top 10 style thinking, where tool misuse and trust expansion are treated as core risks. The field is moving toward front-loaded validation, not retrospective cleanup.

Developer-facing AI is creating a new class of NHI trust debt. Tokens, service credentials, and agent connections are being invited into workflows faster than governance can classify them. The result is fragmented accountability across IDEs, browser tools, and remote servers. Practitioners should assume that every added convenience mechanism also adds a non-human identity control obligation.

Security controls must move to the point of agent action. The important question is no longer whether code will be scanned eventually, but whether unsafe tool calls and generated output are blocked before they leave the working session. That is the difference between governance that observes risk and governance that shapes it.

Semgrep's hackathon trend line signals a broader market shift toward embedded security. Teams under delivery pressure do not wait for separate review stages when they can surface checks in-line with development. For identity and security programmes, that means the control plane is drifting closer to the authoring environment, and practitioners need to decide where authority should sit when humans and agents share the same workflow.

From our research:

  • Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
  • For broader identity context, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the control gaps that emerge as non-human identities multiply.

What this signals

Agentic development is moving security control points earlier in the workflow. That is the right direction for programmes that have struggled to govern secrets and tool access after code has already been produced. The teams that win here will be the ones that can enforce policy inside the authoring environment, not after deployment.

Trust in developer-side NHI will become a measurable governance issue. If a workflow exposes credentials, extension access, or MCP server calls without clear ownership, it creates identity debt that spreads across the engineering stack. Practitioners should expect more pressure to prove where non-human access begins, how it is scoped, and when it is revoked.


For practitioners

  • Classify every MCP connection as a trust decision Inventory which agents, IDEs, and browser tools can reach internal services, then require explicit approval for each MCP server and remote tool path before it can access code, secrets, or context.
  • Move scanning into the authoring session Run deterministic security checks before generated code leaves the browser or IDE, so unsafe patterns are blocked at the point of creation rather than discovered in later review stages.
  • Separate model choice from control enforcement Allow teams to swap LLMs for cost or quality reasons, but keep policy enforcement, secret detection, and code validation independent of whichever model produced the output.
  • Vet external tooling like any other third-party access path Apply the same posture review discipline to extensions and MCP servers that you would use for vendor access, including code review, permission scope review, and revocation when trust changes.

Key takeaways

  • MCP is turning agent connectivity into an identity governance problem, not just a developer convenience.
  • Security checks are moving into the authoring session because delayed review leaves too much trust exposure.
  • Teams should treat browser tools, IDE extensions, and agent connections as governed access paths with explicit scope and revocation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10The article focuses on agentic workflows, MCP, and tool misuse risk.
OWASP Non-Human Identity Top 10NHI-03External tool access and secrets exposure are central NHI governance concerns.
MITRE ATT&CKTA0006 , Credential Access; TA0007 , Discovery; TA0009 , CollectionThe supply chain and tooling risk centers on credential theft and sensitive code access.
NIST CSF 2.0PR.AC-4The post is fundamentally about access governance and tool trust boundaries.
NIST AI RMFGOVERNAgentic workflows require explicit accountability and oversight structure.

Map agent connections and tool permissions to agentic AI controls before enabling execution.


Key terms

  • Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
  • Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
  • Pre-flight inspection: Pre-flight inspection is a control pattern that checks a tool, server, or generated output before it is allowed to proceed. In AI-assisted development, it means verifying posture and scanning for risky patterns before code or actions leave the session.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

  • Project-level examples from the hackathon, including how teams wired security scans into MCP-enabled development flows.
  • Specific workflow patterns for browser-based AI coding and the guardrails used to keep generated code under inspection.
  • The design choices behind multi-LLM evaluation and how teams compared output quality, speed, and security characteristics.
  • The practical shape of pre-flight checks for external MCP servers, including posture review and code scanning steps.

👉 Semgrep's full post covers the hackathon projects, workflow examples, and the security controls teams used in practice.

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 building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org