AI security scales on architecture, not model pricing

At a glance

What this is: This is an analysis of why enterprise AI security depends on architecture and routing, with the key finding that deep AI scanning cannot be applied everywhere without breaking the economics of AppSec.

Why it matters: It matters to IAM and security practitioners because the same budgeted-routing logic increasingly governs secrets, code, and workload identity decisions, especially where AI tooling touches developer workflows and runtime access.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Cycode's analysis of why AI security scales on architecture, not model pricing

Context

AI security in enterprise development is increasingly a routing problem, not just a detection problem. When code volume, AI-assisted coding, and repository sprawl all grow faster than review capacity, teams have to decide where expensive analysis is justified and where cheaper controls should remain the first line of defence.

That makes the identity and access dimension unavoidable. Developer workflows, CI/CD systems, secrets, and AI coding agents all depend on governed access boundaries, and weak routing in one layer can turn into excess privilege or credential exposure in another. The article’s starting point is typical for large engineering organisations, but the scale pressure is becoming universal.

Key questions

Q: How should security teams decide where to use deep AI analysis in code review?

A: Use deep AI analysis only where the marginal value exceeds its cost. The best selectors are risk signals that deterministic tools already expose, such as sensitive data flow, major dependency shifts, high-blast-radius services, and release-bound changes. The goal is not to scan more, but to route expensive analysis toward the places where it can change a security decision.

Q: When does AI scanning create more risk than it reduces?

A: AI scanning becomes risky when teams rely on it as the primary control and let the routing layer go ungoverned. If the selector is stale, opaque, or based on weak heuristics, expensive scans will miss the highest-value targets while producing a false sense of coverage. That is a governance failure, not a model failure.

Q: What do organisations get wrong about AI security coverage?

A: They often treat AI as a single category and then count tool coverage as governance. That creates a false sense of control because identity, cloud, data, and endpoint layers are only inputs. Real governance requires knowing which systems can act, what they can access, and whether their behaviour stays inside intended bounds.

Q: How should identity teams think about AI coding agents in secure development workflows?

A: Treat AI coding agents as governed software entities, not passive features. If they can access repositories, context, or tools, then their permissions, session boundaries, and approval paths need explicit control. The key question is not whether the model is smart enough, but whether its access is scoped tightly enough to the task.

Technical breakdown

Why AI scanning economics favour a layered control model

AI-driven code analysis is expensive because reasoning over whole repositories or release trains requires far more compute than deterministic pattern matching. That cost gap does not disappear as models get cheaper, because the workload scales with code volume, diff size, and contextual depth. In practice, a security platform needs a fast first pass that catches known bad patterns, then a selective second pass for cases where context or exploitability materially changes the decision. This is not about replacing scanners. It is about reserving the expensive step for the places where it adds incremental security value.

Practical implication: keep deterministic controls always on, and reserve AI analysis for changes that materially alter risk.

How routing logic becomes a security control

Once AI analysis is applied selectively, the decision engine is no longer an operational detail. It becomes part of the security model because it determines which code paths, services, or diffs receive deeper scrutiny. That routing should use observable signals such as change graph, ownership, deployment topology, dependency shifts, and exposure changes, not developer self-rating. The moment a heuristic decides what is suspicious, that heuristic itself becomes a control surface that must be governed, tuned, and audited like any other security policy.

Practical implication: treat scan selection criteria as policy, not convenience, and document the signals that trigger deeper review.

MCP and the new boundary between developer tools and security controls

The article’s reference to AI coding agents via MCP points to a broader pattern: AI systems are now acting inside development workflows, not just adjacent to them. That means the security boundary is shifting from isolated code review to governed tool access, context sharing, and action routing across agents and services. If an AI agent can request context, generate changes, and trigger downstream actions, then identity, permissions, and policy enforcement must govern that behaviour as tightly as human-initiated automation.

Practical implication: extend identity and policy controls to AI-assisted development workflows before those tools become operationally normal.

NHI Mgmt Group analysis

AI security routing has become a governance problem, not just a cost problem. When organisations cannot afford deep analysis everywhere, they are forced to choose what gets examined, by whom, and at what depth. That choice determines whether the security programme sees meaningful risk or just generates expensive noise. Practitioners should treat routing as a policy decision, not a procurement optimisation.

Deterministic controls remain the load-bearing layer for enterprise code security. Pattern-based controls are still the only practical way to cover every commit, branch, and dependency change at scale. AI can add context, but it cannot be the sole detection model for high-volume engineering environments. Security teams should preserve the cheaper layer as the always-on control and measure AI only where it improves precision or coverage.

AI-assisted development introduces a new identity boundary around the coding workflow. When agents can read context, suggest changes, and interact with tools through MCP, they are no longer passive utilities. They become governed software entities whose access and actions need scope, traceability, and revocation. IAM and AppSec teams should align on where human approval ends and machine-initiated action begins.

Selective AI analysis creates a new kind of governance debt if the routing model is not transparent. The more a platform decides what is worth deep inspection, the more important it becomes to explain why a change was escalated and who owns the decision. Without that clarity, teams will not know whether coverage gaps are intentional or accidental. Practitioners should demand auditability for the prioritisation layer itself.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, 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.
• From our research: Explore Guide to the Secret Sprawl Challenge for the lifecycle controls that reduce secret exposure and recovery delay.

What this signals

Token-aware routing is becoming the real control plane for AI-era AppSec. As code volume rises and AI analysis remains computationally expensive, teams will need explicit policy for what gets a deep scan and what stays in the fast path. That makes governance of the routing layer as important as the detection content itself, especially where secrets and privileged workflows converge.

Secret exposure and AI-assisted development are converging into a shared governance problem. The same programmes that manage secrets, build pipelines, and workload access now have to account for AI tools requesting context and influencing code changes. Mature teams will separate baseline detection from selective reasoning and will tie both to identity-bound workflow controls, not ad hoc developer judgement.

For practitioners

• Define routing criteria for deep AI scans Base escalation on signals such as ownership changes, deployment impact, dependency churn, and sensitive data paths. Avoid developer self-reporting as the primary selector because it is inconsistent and hard to audit.
• Keep deterministic controls as the universal first pass Run SAST, SCA, secrets detection, and IaC checks on every commit or PR so that AI is used to enrich decisions rather than cover baseline detection gaps.
• Audit AI-assisted development access paths Map where AI coding agents obtain context, what tool permissions they inherit, and which actions they can trigger through MCP or similar integrations. Remove broad access that is not required for the task.
• Measure coverage against risk, not scan volume Track whether high-blast-radius services, sensitive code paths, and release candidates are actually receiving deeper inspection. A large number of AI scans is not proof of control effectiveness.

Key takeaways

• The central risk is not that AI is too expensive, but that teams will spend it in the wrong places and mistake activity for coverage.
• Enterprise AppSec still depends on deterministic controls for baseline coverage, while AI belongs in selective escalation paths where context changes the decision.
• As AI coding agents enter the workflow, identity, permission scope, and routing policy become part of the security architecture, not just implementation details.

Key terms

• Token Dilemma: The token dilemma is the practical limit on how broadly an organisation can apply expensive AI analysis. It describes the trade-off between deeper reasoning and the cost of running that reasoning across large codebases, where routing decisions matter more than model price alone.
• Deterministic Control Layer: A deterministic control layer uses rule-based, fast, repeatable checks such as SAST, SCA, secrets detection, and policy enforcement. It provides the baseline coverage that makes selective AI analysis economically viable by catching known patterns at scale before expensive reasoning is used.
• High-Blast-Radius Service: A high-blast-radius service is a system whose compromise or faulty change can affect many users, systems, or sensitive data flows. Security teams use the term to prioritise review effort, because changes in these services can materially increase exposure even when the code delta looks small.
• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.

What's in the full article

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

• The practical decision logic used to route expensive AI analysis toward high-value code changes and away from routine diffs.
• How deterministic controls such as SAST, SCA, secrets detection, and policy checks act as the always-on first layer.
• The specific signals the platform uses, including change graph, ownership data, exploitability, and deployment topology.
• Why AI scan volume alone is a misleading measure of security coverage at enterprise scale.

👉 Cycode's full post covers the routing model, layered scanning approach, and the economics behind selective AI analysis.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It is designed for practitioners who need to connect identity controls to real operational workflows.