Notifications
Clear all
Topic starter
19/08/2026 3:43 pm
TL;DR: AI-generated code, MCP servers, and autonomous agents are expanding the software attack surface faster than traditional AppSec controls can track, according to Xygeni’s 2026 comparison of AI security tools. Only 55% of AI-generated code was secure in Veracode’s analysis, while the post argues that AI asset discovery, agentic workflow protection, and supply-chain defense now need to sit alongside SAST and SCA.
NHIMG editorial — based on content published by Xygeni: AI security tools for 2026 and the expanding attack surface
By the numbers:
- Only 55% of AI-generated code was secure in Veracode’s 2025 analysis across 100+ models, which means nearly half of machine-written code still reaches production with vulnerabilities.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do AI coding agents increase supply-chain risk?
A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment.
Q: What breaks when AI asset discovery is missing from a security programme?
A: Without AI asset discovery, teams cannot see which models, agents, MCP servers, or datasets are active, so policy enforcement and compliance reporting become incomplete.
Practitioner guidance
- Inventory every AI asset in the delivery chain Map models, agents, MCP servers, datasets, and AI coding tools across repositories, endpoints, and build systems so unmanaged components do not bypass policy.
- Treat MCP servers as governed machine identities Assign ownership, permission scopes, and change control to each MCP server, then review what files, APIs, and pipelines the server can reach.
- Add runtime enforcement to agentic workflows Block unapproved actions at the developer endpoint or execution layer instead of relying only on post-commit scanning and dependency review.
What's in the full article
Xygeni's full comparison covers the operational detail this post intentionally leaves for the source:
- Per-vendor feature comparison across AI-SPM, DevAI, Shield, CoreAI, and Malware Early Warning
- Pricing model details, including contributor-based tiers and free-tier availability
- Implementation-specific coverage of MCP enforcement, developer endpoint controls, and AI-BOM export
- Named product limitations and fit-for-purpose guidance for different team sizes
👉 Read Xygeni's comparison of the top AI security tools for 2026 →
AI security tools in 2026: are your AppSec controls keeping up?
Explore further
19/08/2026 4:21 pm
AI security tooling is becoming a governance layer for machine actors, not just a scanning layer for code. The article correctly frames AI assistants, agents, and MCP servers as part of the security perimeter because they behave like machine identities with reach, privilege, and decision paths. That changes the operating model from artifact review to identity-aware control of what the machine can touch. Practitioners should treat AI security as an extension of IAM and PAM into the SDLC.
A question worth separating out:
Q: How can organisations tell whether their AI security model is actually working?
A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served. If those three signals cannot be correlated in one incident view, the model is likely monitoring access without governing behaviour. That is a visibility gap, not a complete AI security posture.
👉 Read our full editorial: AI security tools are redefining the SDLC attack surface in 2026
