“We’ve spent the last decade securing code. But now, we must ask: who is writing it—and can they be trusted?”

The Shift No One Is Talking About

For years, cybersecurity has focused on the artifact: the code, the vulnerability, the dependency, the binary. Entire industries—ASPM, SAST, SCA, CNAPP, CSPM—are built around what gets shipped into production.

But the attack surface has shifted upstream.

In an AI-augmented, globally distributed development environment, the next logical question isn’t “What does this code do?” but:

“Who created this—and what behavior led to it?”

The truth is stark: we’ve been securing outcomes, not origins.

And attackers know it.

From Code Scanning to Contributor Accountability

Let’s break this down:

Old Paradigm	Emerging Paradigm
Scan code for known flaws	Evaluate the trustworthiness of the human (or agent) contributing it
Alert after merge	Detect risky behavior before commit
Focus on repo state	Focus on developer and AI agent actions
Secure systems	Secure the people and processes that generate them

We’ve reached a point where static analysis and post-facto vulnerability correlation can’t keep up with:

• AI agents writing code autonomously
• Shadow developers accessing source from unknown locations
• Teams shipping faster than legacy scanners can analyze

The new security perimeter isn’t your firewall.

It’s your developer—and the AI agent impersonating one.

The Problem: Behavioral Blind Spots in the SDLC

Most security teams have no visibility into:

• Who actually authored the commit (versus who’s attributed)
• Whether an AI agent wrote part of a function
• If a senior dev suddenly changed behavior patterns
• When PRs are rubber-stamped by bots or ghost reviewers
• Why a trusted engineer starts pushing code at 3AM via a new device

None of this shows up in ASPM, SAST, CNAPP or GitHub audit logs.

This behavioral blind spot is now a systemic risk—one that traditional tools weren’t designed to cover.

The Next Control Point: Behavior, Identity, and Context

Every security transformation has a control point—the place where decisions are made, policies enforced, and workflows anchored.

• In identity, it was Okta.
• In cloud, it was AWS IAM and security groups.
• In endpoint, it was the EDR console.
• In AppSec, ASPM platforms tried to unify scanners.

The next control point is emerging quietly but decisively:

The place where developer and AI agent behavior is observed, evaluated, and enforced.

It’s a new trust layer—one based not on static permissions, but on dynamic actions.

What This Control Point Enables

Once you observe who is writing code and how they’re doing it, you unlock a new class of security capabilities:

• Block risky commits before they hit the repo
• Score developer and agent trust based on historical patterns
• Detect account takeovers or insider threats by behavior deviation
• Enforce AI-agent coding policies based on training lineage or approval trails
• Route remediation to the right actor, not just the right artifact

In short: you shift from triage to prevention, from vulnerability management to trust governance.

What to Look For in This New Layer

As a CISO or platform engineering leader, you should start asking:

• Do we know who is actually writing our code?
• Can we detect behavioral anomalies in our own SDLC?
• Do our existing tools let us enforce identity-based policy, not just scan code?
• Are we blindly trusting the outputs of AI agents in prod?
• How would we know if a trusted dev account was quietly compromised?

If your current AppSec stack can’t answer these questions, it’s not your fault—it wasn’t designed for this world.

What Comes Next

The software creation pipeline is no longer human-only.

It’s a hybrid battlefield of:

• Human engineers (on-prem, remote, contractors)
• AI agents and copilots (internal, vendor, open source)
• Bots, CI/CD, shadow tools, and third-party platforms

We need security platforms that don’t just look at the code—but look at the actor and context behind it.

This is not just a product category. It’s a mindset shift.

We’re entering an era where developer identity and behavior are first-class security primitives.

Final Thought

You can’t secure what you don’t trust.

And you can’t trust what you don’t observe.

It’s time we stop asking only “What code got merged?”

And start asking:

“Who wrote this? Why? And do we trust them enough to ship it?”

That’s the next control point.

And the companies that build it—or adopt it first—will own the future of software security.

See DevSPM in Action

Ready to bring visibility to the most critical layer of your SDLC?

→ Book a live demo and see how Archipelo helps teams align velocity, accountability, and security at the source.

About the Authors:

This article was authored by Matthew Wise, CEO & Cofounder Archipelo