Why agent projects keep calling security last, and pay for it

A proof of concept spins up in a day, so the team races ahead and assumes security can be bolted on later. By launch, the architecture has hardened around its gaps, and the fix is a redesign.

B

Balagei G Nagarajan

4 MIN READ


A fast-moving prototype train with security standing on the platform watching it leave, then catching up at a costly junction
Treat security as a design input on the first sprint, not a gate before launch.
— from “Why agent projects keep calling security last, and pay for it”

Key facts.

  • Security has historically been a late adopter in technology cycles, which perpetuates a bolt-on model rather than a built-in one. The shift-left fix is to involve security at design, not review.source
  • Gartner projected that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.source
  • Classic SDLC economics: a defect costs far more to fix after release than at design, and security defects follow the same curve, which is why late security work is expensive.source
  • Enterprise agents now touch customer data and core infrastructure, widening the gap between what an agent can do and what security can observe or control if it arrives late.source

Why does the agent build specifically invite this?

Because the easy part and the hard part are misaligned in time. Standing up an agent that calls a few tools and answers well is fast, so the proof of concept lands early and creates momentum. The hard part, scoping permissions, handling untrusted inputs, isolating identity, and tracing decisions, is invisible in that demo because the demo had no attacker, no production data, and no audit requirement. So the team ships the easy part and defers the hard part, and the architecture sets around the deferral. When security finally looks, it isn't reviewing a design, it's being asked to retrofit one.

The shifting boundary makes it worse than traditional software. An agent connects an unpredictable model to a scaffold of tools, memory, and APIs, and every new connection is a new part of the attack surface. Add those connections without security in the room and each one becomes a decision that has to be re-litigated later, under load, with the clock running.

Waterfall chart showing the cost to add a security control rising sharply from design to post-launch for an agent project

How do teams move security earlier?

Treat security as a design input on the first sprint, not a gate before launch. Bring the security owner into the architecture decisions: which tools the agent may call, how each tool result is trusted, what identity it runs under, and what gets traced. Those are cheap when they're choices and brutal when they're retrofits. Shift-left isn't a slogan here, it's the difference between a control that's a config line and a control that's a redesign of a system already serving traffic.

DecisionSecurity in at designSecurity in at review
Tool permissionsScoped on first wire-upRe-audit everything reachable
Untrusted inputRule set before launchRework data flow under traffic
Agent identityIsolated from day oneUntangle inherited sessions
Audit traceOne logging layerReconstruct missing history

Once tools and permissions are baked in, the controls become a rebuild, and a stronger model doesn't let you skip it, since adaptive attacks broke 12 defenses and Gartner projects 40% scrapped by 2027. (source)

A Pattern Intelligence Layer is what makes security-at-design practical instead of aspirational. Reliability and security at the pattern level mean scoping, untrusted-input handling, identity, and tracing are standing properties of how the agent runs, available from the first sprint rather than assembled before launch. The team keeps its speed on the easy part, and the hard part is already in place, so security is in the room from the start instead of catching the project at the expensive junction.

Frequently asked questions

Isn't bringing security in early going to slow the POC?
No. At design, the controls are config and one logging layer. The slowdown happens later, when security has to retrofit them into a hardened architecture under production load.

what's the cost of getting this wrong?
Redesigns and cancellations. Gartner projected over 40% of agentic AI projects scrapped by end of 2027, with cost and governance among the reasons. Late security work feeds directly into that.

Can a better model reduce the need to involve security early?
No. Frontier agents still fall to adaptive attacks. The controls live around the agent, so security has to shape the architecture regardless of which model you choose.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.