Notifications
Clear all
Topic starter
02/08/2026 12:16 pm
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.
NHIMG editorial — based on content published by Semgrep: an analysis of MCP, agentic AI workflows, and secure development patterns
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Semgrep's analysis of MCP, agentic AI workflows, and secure development patterns →
MCP in developer environments: what it means for security teams?
Explore further
02/08/2026 1:18 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP is becoming the backbone of agentic developer workflows
