AI-Era Cybersecurity, Part 2: Building the System Context, Governance and Agent Identity

Part 1 of this series walked through why AI has compressed the gap between a vulnerability's disclosure and its exploitation from months to hours, laid out the lifecycle every vulnerability goes through, and mapped Project Glasswing, OpenAI Daybreak, Project Lightwell, Big Sleep, and CodeMender onto that lifecycle. The short version: discovery has gotten fast. Deciding what matters, fixing safely, and governing the automation doing the work have not caught up.

This second part covers that second half, the part most vendor announcements leave out.

The Layer Most Announcements Skip: Context

The three programs above, and the tools around them, mostly strengthen discovery and fixing. What most enterprises actually lack is not more findings. It is useful context about the findings they already have.

A vulnerability score alone does not say whether the affected component is deployed, reachable from the internet, connected to sensitive data, or sitting in a business-critical service. CISA's four-question test, built directly into Binding Operational Directive 26-04, is a practical version of this same idea applied to federal patch deadlines.

This is exactly the argument I made in Graph Engineering: The Layer After Loop Engineering. Enterprise systems are defined by relationships: identities to permissions, permissions to cloud resources, resources to data, services to code, code to dependencies. Security risk lives in those same relationships, which is why an asset graph or attack-path view often does more for prioritization than another scanner.

Mapping Everything to the Lifecycle

Putting programs, tools, and supporting frameworks on the lifecycle diagram makes coverage and gaps easier to see.

The gap is visible immediately. Nothing here covers "know what you run." No program can protect a software list that does not exist, which is why that step has to be handled internally, using SBOMs and dependency inventories, before any of the tools above add real value.

Supporting work around the big three programs targets a second-order problem: faster discovery means more reports than open source maintainers can review. Anthropic has partnered with the Open Source Security Foundation's Alpha-Omega project to help maintainers triage incoming reports, and OpenAI's Daybreak commitment includes direct funding for groups such as Trail of Bits. Palo Alto Networks has also worked with IBM and Red Hat so its network-level protections can block attacks while a Lightwell fix is tested and rolled out, a practice known as virtual patching. It buys time. It does not replace the fix.

AI Agents Are Identities Now, Not Just Tools

There is a part of this system that most vendor comparisons leave out entirely: the AI agents doing the work are themselves a new attack surface that needs governance.

An agent that reads source code, opens a pull request, queries a knowledge base, or changes a cloud setting is acting with real permissions. It should be treated the same way a service account or a contractor's login is treated, not as a feature toggled on inside a chat window.

Every production agent should have a unique identity rather than a shared credential. Permissions should be scoped to the task. Tool access should be explicit. Sensitive data should be classified before it enters a prompt or a retrieval pipeline. High-impact actions, like deploying a patch or changing an IAM policy, should require a human approval step, which is exactly the control that DeepMind applies to CodeMender's own patches.

A mature security program should be able to answer, at any time: what did the agent access, what tools did it call, what changed, which policy allowed the action, who approved it, and can the agent's access be revoked immediately if something goes wrong.

I wrote about the underlying discipline this requires in Production-Grade AI Agents and in From Prompts to Harnesses: How AI Engineering Has Grown Up. Memory boundaries, tool controls, guardrails, and observability are not optional extras for a chatbot. In a security context, they are exactly the controls that keep an autonomous remediation agent from becoming its own incident.

The Rulebooks That Decide What Gets Fixed First

Tools tell you what is possible. Frameworks tell you what to prioritize and how to prove you did it.

The frameworks without a specific source link above are widely documented industry standards rather than a single paper or announcement; readers can find the current OWASP, CVSS, and SLSA specifications through their respective maintaining bodies (OWASP Foundation, FIRST.org, and the SLSA project) rather than a single citable report.

A Practical Layered View

Combining Part 1's tools and this part's context and governance layers gives a structure any team can use to check its own coverage.

Layer 1 remains the most commonly skipped step, and the one no vendor tool can fix for you. My earlier piece on a private, segmented network architecture using Terraform and Ansible is one example of reducing exposure at Layer 5 before a bug is even found: fewer exposed entry points means fewer urgent fixes later.

Proving a fix actually worked, at Layer 6, depends on the same operational discipline covered in Incident Management and the Rise of AI SRE Agents and How AI Is Actually Changing SRE Tools, Part 2. Security and SRE teams increasingly share telemetry, runbooks, and the same requirement that automation be observable and reversible.

Measure What Actually Matters

Counting findings or closed tickets is not the same as reducing risk. More findings can mean better visibility. Fewer tickets can mean issues were closed administratively rather than actually fixed.

The question behind every metric is the same one CISA is now asking by regulation: are you reducing real risk faster, without creating a new source of operational risk in the process?

Where to Start

You do not need an invitation to any of the programs from Part 1 to begin.

Questions Worth Asking Any Vendor

Conclusion

None of the programs covered in this series replace a basic vulnerability management program. Glasswing, Daybreak, and Big Sleep speed up discovery. CodeMender and Lightwell speed up safe delivery of fixes. CISA's directive and the supporting frameworks tell you what to fix first. Virtual patching covers the gap while you wait. Agent identity and governance keep the automation itself from becoming a new risk.

The strongest organizations will not be the ones that adopt the most tools from Part 1. They will be the ones that connect discovery, context, prioritization, remediation, governance and learning into one repeatable loop, and that treat their AI agents with the same identity discipline as any other privileged account.

Start by finding the weakest link in that loop. If you cannot see your assets, fix discovery. If you cannot tell which findings matter, fix context. If your backlog keeps growing faster than you can clear it, fix remediation capacity. If an AI agent can act without clear boundaries, fix governance before you give it more access.

Further Reading

• Graph Engineering: The Layer After Loop Engineering
• Production-Grade AI Agents
• From Prompts to Harnesses: How AI Engineering Has Grown Up
• Incident Management and the Rise of AI SRE Agents
• How AI Is Actually Changing SRE Tools, Part 2
• Private VPC Network: Terraform and Ansible automation