By Ross Weatherford, Senior Director of National Security Programs at Coder

Over the last several months, the conversation inside the IC about AI-augmented development has moved fast. Platform engineering is replacing the monolithic software factory. The builder population is expanding beyond credentialed engineers to analysts, operators, and specialists who carry the community’s most irreplaceable asset: domain expertise. Both of those shifts are real, and together they create a problem the IC has not yet solved.

More builders mean more environments. More environments mean more surface area. And when autonomous AI coding agents are introduced into that expanded landscape, agents that can access repositories, generate code, and execute tasks without continuous human direction, the blast radius of a misconfiguration, a compromised dependency, or an insider threat expands in ways that traditional security models were not designed to handle.

This is not a theoretical concern: Georgia Tech’s Systems Software & Security Lab tracked 35 new CVE entries in March 2026 alone that resulted directly from AI-generated code, up from six in January and fifteen in February. Veracode’s 2025 GenAI Code Security Report found that AI-generated code contains 2.74 times more vulnerabilities than code written by humans. Apiiro found AI-generated code creates 322 percent more privilege escalation paths. The democratization of development is genuinely transformative, yet it comes with a governance challenge that the IC needs to get ahead of before the scale arrives, not after.

The agentic AI risk layer

The security risks of AI-assisted coding are real enough on their own. But AI coding agents, autonomous systems that do not merely suggest code but take actions, access file systems, call APIs, and modify repositories, introduce a qualitatively different class of risk.

These agents can access repositories outside their intended scope, generate verbose outputs that inadvertently leak sensitive context, and escalate privileges in ways that no human developer would, simply because the agent’s optimization function does not include the same threat model a trained engineer carries. Check Point Research disclosed critical vulnerabilities in a major AI coding tool in February 2026, including configuration injection flaws that allowed remote code execution the moment a developer opened a compromised project, and the OpenClaw supply chain attack confirmed over 1,100 malicious packages in an AI agent ecosystem, roughly one in five packages in the affected repository.

This is already informing how the Intelligence Community approaches AI deployment. The question is no longer whether AI agents will operate in IC development environments, because they will. The question is whether the governance infrastructure will exist when they do.

Human on the loop as operational reality

The IC cannot have a human reviewing every line of AI -generated code. With developers estimating that 42 percent of committed code is already AI-assisted, and increasing, that model is not merely impractical, it is impossible. Yet the alternative is not abandoning oversight, but moving oversight to where it can actually operate: the policy and boundary level rather than the task level.

In practice, this means immutable audit logs that capture what every agent did, when it did it, and in what context; toolchain limits that constrain what an agent can access so a coding assistant working on a frontend component cannot reach into a classified data pipeline; sandboxed execution environments where agent generated code runs in isolation before it touches anything in production; and SIEM integration that treats agent activity as a first class telemetry source rather than an afterthought bolted onto existing monitoring.

The shift from human in the loop to human on the loop is not about reducing accountability. It is about making accountability scalable. A senior engineer reviewing a pull request is valuable, but a platform that prevents the pull request from ever containing unauthorized access patterns is more valuable, because it operates continuously and does not depend on one person’s attention on a random Tuesday.

What coherent governance looks like across agencies

Each IC agency has distinct missions, infrastructure, and risk tolerances. No one is arguing for a single centralized governance platform because that would repeat the exact mistake the monolithic software factories made. What the community needs is shared baselines.

ODNI is already moving in this direction. In March 2026, ODNI announced it is building the policy framework, governance, and standards to accelerate AI adoption across the IC, and DNI Gabbard has since announced the largest ever IC cybersecurity investment and modernization effort, which includes policy standards for AI in cyber defense, a shared repository for security reviewed applications, and expanded threat hunting capabilities.

The architecture this points toward is one in which ODNI sets minimum standards for red teaming, auditability, and incident reporting. Meanwhile agencies deploy on their own infrastructure and use their own toolchains, yet produce logs and controls compatible with a common framework. It is better understood as the difference between requiring everyone to use the same car and requiring everyone to drive on the same side of the road, because the goal is interoperability rather than uniformity.

Intelligence Community Directive 505 on Artificial Intelligence, combined with NIST’s Secure Software Development Framework and SP 800-218, provides the policy scaffolding, but what has been missing is the operational infrastructure that makes those directives enforceable at the speed development actually moves.

Compliance that travels with the workspace

The most durable governance model is one in which policy is embedded in the environment itself, not layered on top of it after the fact.

The principle is consistent across all of this: when compliance is embedded in the environment rather than layered on top, it scales. Small platform teams define it once in code. Every builder, human or agent, inherits it automatically. The governance model for AI agents is not a new problem — it is the same infrastructure problem, applied to a faster and less predictable actor.

When a workspace template defines what an AI agent can and cannot do, what repositories it can access, what actions it can take, and what boundaries it must respect, that governance is structural, and it does not depend on the individual developer configuring it correctly, and it does not depend on a security team reviewing every session, because a workspace that meets governance requirements on an unclassified network works identically on a classified one, since the controls are defined in the template rather than in a separate policy document that someone has to remember to apply.

Coder’s approach to agent boundaries, task definitions, and centralized environment management give security teams visibility and control over what AI agents do inside builder workspaces without requiring those teams to be present for every session, so the platform becomes the enforcement mechanism and governance becomes infrastructure.

The cost of waiting

Provisioning speed, prototype speed, the speed to turn domain expertise into mission capability — those are the stakes this argument has been building toward. But the most consequential speed question is not about development environments. It is about how fast adversaries are moving while the IC deliberates.

China is now estimated to spend roughly $2 billion annually on AI enabled military systems, comparable to United States levels, and has deployed autonomous ground robots, AI driven drone swarms, and machine learning systems for target recognition and operational planning at scale and the PLA is actively restructuring its joint operational frameworks around AI driven combat platforms. Russia, meanwhile, is taking a different but equally consequential approach, rapid, iterative deployment of autonomous systems in actual combat in Ukraine, refining capabilities through operational feedback loops that compress the development cycle in ways traditional procurement cannot match; Russian and Chinese officials held formal consultations on military AI cooperation in Moscow in November 2025, and they are not waiting to resolve governance before deploying, because they are deploying and adapting in parallel.

The IC’s advantage, and it is a genuine advantage, is that it can move fast and build trust simultaneously. Democratic accountability, rigorous oversight, and transparent governance are not obstacles to speed. When done correctly, they are accelerants, since they build the institutional confidence required to deploy AI capabilities broadly rather than keeping them confined to pilot programs and proofs of concept that never scale.

But that advantage has a shelf life. The Pentagon’s fiscal year 2026 budget requests $13.4 billion for AI, so the investment is there, the policy direction from ODNI is there, and the commercial technology to enforce governance at the platform level exists today. What remains is the execution, standing up the infrastructure that makes governance operational before the scale of AI augmented development outpaces the community’s ability to oversee it.

The organizations that get this right will not be the ones that moved cautiously. They will be the ones that built governance into their development infrastructure from the start, so that when the scale arrived, the trust was already in place.

The governance infrastructure the IC needs is not a future requirement. It is a current one. The factory has already given way to the framework. The builder population is already expanding. The agents are already operating. The window to get ahead of it is not as wide as it might appear.

About the author

Ross Weatherford is a Director of National Security Programs at Coder, where he partners with DoW, Intelligence Community, and defense contractor customers on secure, compliant development environments and agent ready workspaces. With over two decades in cybersecurity and federal technology, Ross has led cyber architecture and engineering teams at Northrop Grumman across classified space and ground systems and served as lead solutions architect for the largest account in national security programs at Red Hat. He holds CISSP, CCSP, RHCSA, and AWS certifications.

About Coder

Coder is the only AI development Infrastructure that unifies development environments, AI governance, and autonomous agents into a single, self-hosted system. It enables enterprises to move development off unmanaged endpoints and into standardized, policy-controlled environments where both builders and AI agents operate in parallel safely. With centralized governance, AI model-agnostic flexibility, and full observability, Coder allows organizations to scale AI adoption without compromising security, compliance, or cost control. Learn more at coder.com.

The post Governing What You Cannot See: How the IC Should Think About Security and Oversight for AI Augmented Development appeared first on Intelligence Community News.

By Austen Bruhn, Staff Solutions Engineer — US Public Sector at Coder

The hardest problems in IC software development in 2026 are not technical. They are organizational – it’s the challenge of overcoming mission knowledge gaps between the people who understand the problem and the people who can actually solve it.

The person who best understands a mission gap — the all-source analyst who has spent five years tracking a specific threat actor, the SIGINT specialist who recognizes patterns invisible to anyone outside their collection account — is rarely the person positioned to act on it. That knowledge gets translated into a requirement. That knowledge gets written down as a requirement, then turned into a statement of work and, ultimately, that becomes a contract. Somewhere in that chain, irreplaceable operational insight loses most of its fidelity.

This bottleneck rarely makes it into conversations about IC modernization. Infrastructure debt does. Talent retention does. Procurement timelines do. But the gap between the people who understand the mission and the people authorized to build tools for it is at least as consequential as any of those. And it’s been widening while the rest of the conversation moved on.

A new kind of builder is emerging

The conversation is starting to shift. CDAOs at major defense primes are investing in citizen developer programs — training analysts, logisticians, and specialists to build workflows, notebooks, and data transformations without traditional coding backgrounds. The Marine Corps Chief AI Officer has pushed for models where operators contribute directly to the tools they use in the field, rather than filing requirements and waiting. Gartner estimates that citizen developers now significantly outnumber professional developers in large enterprises, and the ratio is still moving even in the Defense Industrial Base (DIB).

What’s making this realistic rather than aspirational is the state of AI-assisted development. The DoD’s own Chief Digital and AI Office acknowledged in a February 2026 solicitation that its software development workforce “currently lacks standardized, enterprise-wide access to AI-enabled coding tools that are commonplace in the commercial sector,” and that the gap “limits developer productivity [and] slows the delivery of mission-critical software.” That gap is exactly the opportunity. An analyst who can describe a problem clearly, evaluate whether a proposed solution makes sense, and iterate is someone who can build useful things today in a way they couldn’t before. The underlying technical knowledge required has dropped significantly. The domain expertise those analysts already carry has not.

What this looks like on the mission

Take an OSINT analyst who has identified a gap in how the community is processing a new collection source.

Under the model most programs still operate on, that insight gets written down as a requirement. It gets reviewed, prioritized, and eventually turned into a statement of work or added to an existing program. Months later—sometimes longer—there’s a tool. Whether it still fits the original need is a separate question.

The alternative looks different.

That same analyst opens a compliant development environment, selects a template aligned to their data stack, and starts prototyping. An AI coding assistant helps fill in the gaps where they don’t have deep engineering experience. Within a few days, something is testable. Within a week, it’s shareable.
The key difference isn’t just speed. It’s fidelity. The person who understood the problem is still the one shaping the solution.

DoD’s Advana platform—a centralized, CAC-enabled data and analytics environment—has already shown what happens when that barrier is removed. Analysts can access data, build workflows, and share useful outputs without standing up a program first.

The opportunity for the IC is extending that model beyond analytics into broader development, so domain experts can do more than analyze data. They can build the tools they need, when they need them.

The infrastructure problem underneath all of this

None of it happens if standing up a compliant workspace takes two weeks or longer.

That’s the constraint that kills citizen developer initiatives before they start. When provisioning access to a development workspace still means navigating approvals, provisioning steps, and configuration work that only a handful of people understand, the friction is high enough that only few engineers bother. Domain experts who might prototype something valuable just don’t. The opportunity cost is invisible, so it doesn’t show up in any program’s risk register.

There are also constraints that don’t go away: accreditation boundaries, ATOs, and networks that weren’t designed for rapid iteration. Those are real, and they shape what’s possible.

Platform engineering addresses this at the source. Small, focused platform teams define what compliant development looks like, build it into self-service templates, and let anyone with access spin up a workspace in minutes — pre-configured, policy-compliant, ready to go. Workspace infrastructure is defined as code. Security controls are built in rather than added after the fact. The same template that works on an unclassified network works identically on a classified one, in an air-gapped facility, without asking the builder to re-platform when they change networks.

That last point matters more than it might sound. A senior analyst willing to try building something shouldn’t have to become a system administrator first. The infrastructure either gets out of the way or it doesn’t.

Security as the floor, not the door

The compliance model most programs inherited treats security as a gate: something you pass through at the beginning or prove at the end. That made sense when developers were a small, specialized population that could be managed through access controls and vetting processes.

It breaks down when the goal is to expand who builds. You can’t selectively enforce compliance based on whether someone has a traditional development background. What you can do is move the enforcement into the platform itself. Toolchain access is defined before anyone writes a line of code, audit logs are generated automatically, and policy is traveling with the workspace rather than depending on individuals to follow procedures correctly every time.

In a platform model, the controls are defined once and enforced everywhere. NIST’s Secure Software Development Framework (SSDF) has been making this argument at the policy level for years: security should be continuous and integrated, not a final checkpoint. Platform engineering is how that principle becomes operational reality. When compliance is built into the platform, it stops being the mechanism that determines who gets to start building.

What the IC actually stands to gain

The agencies that figure out how to turn domain expertise into repeatable, shareable capability will have something that can’t be easily replicated by competitors or contractors. The analyst who developed a novel approach to a collection problem retires, and under the current model, that approach retires with them — maybe preserved in a report, maybe not. A Science study published in early 2026 found that productivity gains from AI-assisted coding were sharpest among experienced practitioners — not junior developers. The IC’s senior analysts, operators, and specialists are exactly that population.

When those people can build tools that encode what they know, expertise becomes institutional rather than individual. An analyst’s data transformation becomes a template. A targeting workflow becomes a starting point for the next team. The distance between having an idea and building something useful around it starts to compress.

The competitive pressure here is real. Near-peer adversaries are moving aggressively to apply AI to their own software development and autonomous operations. The IC’s response can’t just be better infrastructure for the engineers it already has. It needs infrastructure that expands who gets to build, and that starts with ensuring the people who understand the mission are the ones shaping the tools.

The IC’s advantage will belong to the organizations that stop separating those two groups at all.

Austen Bruhn is a Staff Solutions Engineer for the US Public Sector at Coder, where he works with government and defense programs on secure, compliant development infrastructure across classification levels.

Coder is the AI software development company leading the future of autonomous coding. Coder helps teams build fast, stay secure, and scale with control by combining AI coding agents and human developers in one trusted workspace. Learn more at coder.com.

About IC Insiders

IC Insiders is a special sponsored feature that provides deep-dive analysis, interviews with IC leaders, perspective from industry experts, and more. Learn how your company can become an IC Insider.

The post Who Builds the Mission Now? How the IC Is Expanding the Definition of a Developer appeared first on Intelligence Community News.

By Amanda Phelps, Head of Global Public Sector Partnerships and Alliances at Coder

I have watched talented government and defense teams pour years of effort into software factories, and watched those same factories quietly become the thing slowing development down. That is not a failure of the people who built them. It is a signal that the model has run its course.

For the past decade, “software factory” has been the defining concept of digital transformation across the Department of Defense and the Intelligence Community. Initiatives like Platform One, Kessel Run, Black Pearl, and Kobayashi Maru proved that modern DevSecOps could work in sensitive environments, that containers could survive an ATO, and that developers did not need to wait months for infrastructure. Those teams deserve every bit of credit they receive.

But the model they pioneered is now collapsing under its own weight. The factories we built were cathedrals. What the mission needs now is something more flexible, like a framework.

The untenable cost of the monolith

The original software factories had to be centralized and monolithic. Kubernetes was not yet authorized. CI/CD pipelines could not yet satisfy NIST 800-53 controls. GitOps was unproven at the classification boundary. Early adopters bore enormous compliance burdens just to establish that modern development was possible in secure environments at all.

The fundamental problem is that monolithic factories try to be everything to everyone. A single factory is expected to serve programs building web applications and programs training machine learning models, teams operating in the cloud and teams in air-gapped facilities, experienced engineers and teams encountering modern development for the first time. That breadth creates impossible tradeoffs. Make the factory standardized and you alienate programs with specialized requirements. Make it flexible and you drown in configuration complexity until the factory itself becomes the bottleneck.

These factories also became single points of failure. When key personnel leave, institutional knowledge walks out with them. Platform teams get consumed by access requests, exception handling, and organizational overhead. The infrastructure meant to accelerate delivery starts slowing it down.

A maturing commercial ecosystem changes the calculus

What changed is that commercial technology matured in ways government-built factories cannot match.

Purpose-built infrastructure automation tools now treat cluster provisioning, configuration management, and infrastructure-as-code as solved problems. Declarative approaches — defining the desired state and letting automation handle the realization — enable agencies to enforce discrete access controls, reduce insider risk, and remove human error from provisioning. These capabilities are core to the tools, not incidental to them.

For the developer experience specifically, the shift has been equally significant. Secure, cloud-based development environments address one of the most persistent pain points in classified software development: standing up a compliant workstation and becoming productive. Developers in air-gapped facilities typically wait days, and weeks or months are not uncommon, for properly configured systems. Modern development environments can be provisioned in minutes from an approved template, with security controls built in rather than bolted on. Coder provides this capability for IC and DoD programs — teams define workspace infrastructure as code, enforce policy at the platform level, and support everything from unclassified development through classified and disconnected environments without changing the developer workflow.

This approach also shifts the maintenance burden from overworked government platform teams to vendors with engineering resources, SLAs, and dedicated security response. When something breaks, you open a ticket rather than lose months of capability development while someone reconstructs a Kubernetes cluster from memory.

Platform engineering: Smaller teams, greater scale

The successor to the software factory is not another factory. It is a platform engineering model where small, focused teams curate technology choices and define integration patterns rather than building and operating infrastructure from scratch.

This distinction matters enormously for the IC because the scalability problem that killed monolithic factories came down to headcount. When every program office queues behind a central platform team, scaling means hiring more government employees — slow, expensive, and constrained by hiring authorities that often have little relationship with the pace of mission need. When programs consume infrastructure through self-service catalogs built on proven commercial technology, scaling becomes a software problem. That is solvable.

In this model, platform teams do three things well:

1. Define what compliant deployment looks like
2. Curate the approved components that programs draw from, and
3. Provide self-service interfaces that let development teams operate within security guardrails without creating a ticket for every resource request

The result is portable compliance. A workspace template that meets security requirements in an unclassified environment should work the same way on a classified network and function without modification in an air-gapped facility. Policy travels with the infrastructure.

The cross-domain problem

For the IC specifically, the platform engineering transition carries an additional imperative that defense-focused discussions tend to overlook: cross-domain development.

A developer supporting a program that spans multiple classification levels does not simply move between environments. They context-switch between different physical machines, credential sets, toolchains, and organizational processes. Work products moving between domains pass through transfer processes measured in hours or days. Managing cross-domain workflows has historically required dedicated personnel whose primary function is shepherding data across boundaries rather than building capability.

Platform engineering changes this. When development environments are defined as code and centrally managed, it becomes possible to maintain consistent toolchains and security baselines across classification levels while preserving the hard separations that protect sources, methods, and program equities. A developer’s workspace on the low side and their workspace on the high side can be structurally identical. Cross-domain transfer processes can integrate into the development workflow rather than function as afterthoughts. The compliance burden shifts from individuals performing manual procedures to the platform enforcing those procedures automatically.

IC programs are already deploying remote development infrastructure that spans classification boundaries with consistent policy enforcement and without asking developers to re-platform every time they change networks.

The democratization of building

Here is where this transition becomes genuinely transformative — and where the IC has a specific advantage to capture.

The IC has always had a large population of domain experts who are not software developers but who possess operational knowledge no development team can fully replicate. All-source analysts who understand threat actor behavior in ways that cannot be captured in a requirements ticket. SIGINT specialists who recognize patterns in data only visible through years of operational exposure. Collection managers who understand source constraints in ways that lose critical nuance when translated to pure technicians.

Platform engineering, combined with the right development infrastructure, is beginning to make these people builders. Not in the traditional software development sense, but in the sense of constructing tools, notebooks, workflows, and analytical environments that extend individual expertise into repeatable, shareable capability. An analyst who can prototype a data transformation that makes a new collection source exploitable is not writing production software. But they are producing real mission value — in ways that centralized software factories were never designed to support.

The enabling condition is a development environment that removes the infrastructure tax on exploration. When standing up a secure, compliant workspace requires a ticket and a two-week wait, only credentialed engineers do it. When it requires a template selection and a few minutes, the population of people who can meaningfully participate in building expands dramatically. Compliance becomes the baseline from which everyone works, not a gate that filters who can start.

What is actually dying (and what is not)

What is dying is the centralized, monolithic software factory that inserts itself as the critical path for every development team it serves. The model where a single isolated organization controls the infrastructure, tools, processes, and standards for all programs is giving way to something more sustainable.

The mission need those factories served is not dying. It is growing. Agencies still need to compress delivery timelines, elevate security postures without stifling innovation, retain technical talent, and deliver capability at the speed modern threats demand. The difference is that the IC no longer needs to build its own factory to achieve those outcomes. The Air Force’s Platform One has evolved toward a platform-of-platforms model. The Navy has moved to multi-vendor strategies that reduce lock-in and increase operational resilience. Across the IC, organizations are realizing they can adopt proven frameworks and adapt them to their compliance requirements rather than rebuilding from scratch.

The path forward

The question is no longer whether modern DevSecOps practices can work in classified environments. That is proven. The questions now are much harder to solve.

Can we build development infrastructure that genuinely serves the cross-domain operating reality of the intelligence enterprise, rather than forcing developers to absorb that complexity as manual overhead? Can we extend the population of people who build to include analysts, specialists, and operators whose domain expertise is the IC’s most irreplaceable asset? Can we shift enough of the compliance burden into the platform itself that security becomes an accelerant rather than a constraint?

Platform engineering makes all of this achievable. Small teams can support large organizations. Compliance becomes portable and workspaces repeatable across classification levels. The maintenance burden that currently consumes government talent shifts to software. The distance between having an idea and building something useful around it can be measured in minutes.

The factory that tried to control everything is giving way to a platform that enables everyone. That is not a loss. It is the next evolution the mission has been waiting for.

About the Author

Amanda Phelps leads Global Public Sector Partnerships and Alliances at Coder, where she works with government and defense organizations to enable secure, compliant development environments across classification levels. She specializes in creating partnership strategies that accelerate software delivery for programs in the public interest.

About Coder

Coder is the AI software development company leading the future of autonomous coding. Coder helps teams build fast, stay secure, and scale with control by combining AI coding agents and human developers in one trusted workspace. Coder’s award-winning self-hosted Cloud Development Environment (CDE) gives teams the power to govern, audit, and accelerate software development without trade-offs. Learn more at coder.com.

About IC Insiders

IC Insiders is a special sponsored feature that provides deep-dive analysis, interviews with IC leaders, perspective from industry experts, and more. Learn how your company can become an IC Insider.

The post The Software Factory Is Dead, Long Live the Software Factory appeared first on Intelligence Community News.

By Austen Bruhn, DoD/NatSec Architect, Coder

The U.S. Intelligence Community stands at a turning point. The global race for AI supremacy is no longer theoretical. Agentic systems are already in use, adversaries are moving fast, and the mission window for secure adoption is closing.

Around the world, near-peer competitors are using agentic AI to speed up software deployment, automate cyber operations, and reshape how intelligence is built and used. These tools generate and execute code, act independently, and handle development tasks that used to require full teams. The U.S. cannot fall behind—not on speed, and not on security.

At home, federal guidance is pushing forward. Executive Order 14179 and memos like M-24-10 call for bold AI adoption with real guardrails. The IC may not be directly bound by them, but the direction is clear. The mandate is to deploy AI systems that are governed, auditable, and trusted from the start.

The call to action is clear and coming from inside the community: “Entities that augment their activities with AI applications will likely disrupt those that do not,” said CIA Chief Cyber Policy Adviser Dan Richard. CIA Chief AI Officer Lakshmi Raman added, “AI is not just an emerging technology. It is a strategic necessity.” This imperative is not abstract; it lands directly on the desks of IC code builders, who must adapt their workflows to leverage agentic AI securely.

Together, these perspectives underline a common truth: the IC cannot afford to delay. Adoption is inevitable, but it must proceed with an implementation approach that ensures trust, accountability, and security from the start.

Adversaries are already applying AI to accelerate code generation for cyber operations and software deployment. Reporting shows that China’s military innovation agenda emphasizes “intelligentized” systems, including AI-driven software development and autonomous cyber tools (Brookings). For the IC, this raises the stakes: the competition is not just about who fields AI first, but who does so securely. If builders in the IC remain constrained by legacy, decentralized environments while adversaries leverage agentic AI for rapid development, the U.S. risks falling behind in both speed and resilience. This is why secure, centralized, and policy-aligned agentic development environments are a strategic necessity now, not later.

Agentic AI adoption is inevitable. The mission now is to implement it safely, at speed, and at scale.

The opportunity and risk of agentic AI software development

Agentic AI offers builders powerful new capabilities: reading documentation, generating shell scripts, proposing code, and even testing and deploying microservices. For the IC, this means accelerated software development, increased automation within Continuous Integration/Continuous Deployment (CI/CD) pipelines, and freeing mission teams to focus on higher-order analysis.

But with great capability comes new vulnerability. These systems challenge traditional software lifecycle boundaries and introduce risky behaviors, such as:

• Accessing sensitive code repositories unintentionally
• Using tools beyond their approved scope
• Exposing sensitive data through verbose or unreviewed outputs
• Escalating privileges, altering configurations, or attempting unauthorized external communications

These examples illustrate the emergent behaviors that make agentic AI risky in mission environments. They directly inform the safeguards outlined later in this article, from immutable audit logs and toolchain limits to human-on-the-loop oversight and continuous evaluation.

In practice, this means builders must anticipate edge cases rather than wait for them to appear in production. For example, an agent trained to optimize workflows might unintentionally bypass a security step to increase efficiency. Without structured oversight, such a behavior could introduce vulnerabilities into classified systems. Builders are therefore on the frontlines of ensuring guardrails are not just theoretical but actively enforced through controlled environments, continuous monitoring, and deliberate design choices.

From human-in-the-loop to human-on-the-loop

As the volume and velocity of sensor and intelligence data continues to surge, the traditional human-in-the-loop model is reaching its limits. For time-critical operations, humans can no longer process and act on information fast enough. This necessitates a shift toward human-on-the-loop systems, where automated processes execute within defined parameters, and humans focus on strategic oversight, operational boundaries, and ethical constraints.

These practices must be supported by software systems that are adaptive and resilient. Builders should adopt AI-forward methodologies and automation frameworks that maintain rigorous security and governance, including explainable outputs, audit trails, and fail-safe policies. The goal isn’t full autonomy—it’s controlled autonomy.

Raman echoed this balance of oversight and partnership, saying the CIA’s broad approach to AI is focused on “how humans and the AI are working together,” with humans ultimately responsible for oversight, accountability, and intervention when necessary.

Moving from philosophy to practice, this shift in human oversight does not occur in a vacuum. In IC workflows, human-on-the-loop oversight means builders and operators may not review every line of AI-generated code, but they validate that outputs adhere to policy, confirm auditability, and ensure systems cannot access unauthorized data. This balance enables time-critical missions to run at machine speed while keeping accountability and intervention authority firmly in human hands. It is unfolding alongside federal policy designed to accelerate AI adoption responsibly. For the IC, the challenge is aligning this operational reality with governance expectations now shaping the broader federal landscape.

Policy to practice

Federal policy is pushing agencies to adopt AI responsibly and at speed. M-24-10 and M-25-21 highlight the government’s intent to balance innovation with governance. The IC is not bound by these memos, but they set expectations and signal how oversight bodies, Congress, and the public will judge whether the IC is deploying AI effectively and responsibly. The challenge is translating these high-level policies into secure implementation approaches inside classified environments.

The IC’s own Principles of AI Ethics reinforce these expectations: development must be human-centered, accountable, secure, and science-informed. These priorities also align with broader federal standards work led by the National Institute of Standards and Technology (NIST). The AI Risk Management Framework (AI RMF 1.0) emphasizes trustworthy AI through governance, transparency, and continuous monitoring—principles reflected in the safeguards outlined in the next section.

Likewise, Special Publications (SP) 800-218 and 218A stress secure software development practices, code integrity, and supply chain protection, all of which map directly to the IC’s need for rigorous DevSecOps pipelines, audit logging, and boundary enforcement in AI-augmented environments. What follows is focused on implementation approaches: how the IC can translate these principles into operational safeguards in builder workflows.

Securing the development environment

Operationalizing AI agentics for builders within classified or high-sensitivity environments demands a new set of controls:

Control boundaries

Boundary of place – isolate environments: Sandbox agents in hardened, network-limited environments.

Boundary of tools – enforce toolchain limits: Define explicit tool access policies, and block everything else.

Boundary of data – enforce agentic boundaries: Restrict data and system access to prevent unauthorized queries or lateral movement.

Monitoring and detection

Audit all actions: Track all executions to maintain accountability and transparency.

Detect and respond to threats: Forward immutable logs into Security Information and Event Management (SIEM) systems for automated detection of misuse or compromise.

Integrate into DevSecOps (development, security, and operations): Ensure pipelines are AI-aware, scanning generated code and architectures for malicious or insider threat behavior.

Use AI gateway proxies: Enforce data loss prevention (DLP) and inference monitoring for drift, poisoning, prompt injection, hallucination, malicious code, and data leakage.

Operational oversight

Human-on-the-loop verification and evaluation: Maintain human oversight through post-hoc audits of AI-generated code and runtime behaviors.

Raman emphasized that boundaries are critical for ensuring compliance with legal policy and data protections. This underscores the need for agentic boundaries that prevent unauthorized data access and enforce compartmentalization across environments.

Steve Schmidt, Chief Security Officer at Amazon, underscored the accountability challenge of deploying agentic systems: “How do we make sure that the software is doing exactly the right thing every single time, and more importantly, that we can prove what it did to stakeholders and regulators?”

Run dangerous things in a safe place

Coder provides one example of how secure-by-design tools can support the IC’s adoption of AI agentics. Features such as Agent Boundaries (policy-enforced sandboxes that define what an agent can access) and Tasks (auditable, human-verifiable subtasks) demonstrate how AI-augmented coding can be implemented while preserving oversight and compartmentalization.

Another critical safeguard is centralizing access to both AI models and the compute resources that power them. One underappreciated risk is that agentic AI itself can act as a new form of insider threat. A malicious prompt injection or poisoned retrieval source can cause an otherwise trusted agent to generate backdoors, disable safeguards, or leak sensitive data. For the IC, the stakes are even higher: code deployed in classified environments must assume the agent could be compromised. Centralized environments, logging all actions, and enforcing compartmentalized access are essential defenses against both human insiders and AI behaving like insiders. Decentralized, ad hoc environments multiply the risks of misconfiguration, exfiltration, and uneven enforcement. Centralized environments, such as those enabled by Coder, give agencies the ability to enforce boundaries, monitor agentic behavior, and apply consistent controls for both builders and AI agents within a single secured infrastructure.

Yet even the most secure implementations cannot exist in silos. Builders may operate within agency-specific environments, but the risks and safeguards around agentic AI cut across the entire IC. Scaling these safeguards requires more than technical controls. It requires alignment, coherence, and oversight.

Scaling agentic AI across agencies

Each IC agency has distinct missions, data needs, and operational realities, so managing and deploying agentic platforms must remain within their domain. At the same time, the Office of the Director of National Intelligence (ODNI) will set strategic guidance and standards, emphasizing guardrails and oversight rather than control. Looking ahead, Director of National Intelligence Gabbard noted that ODNI 2.0 will “enable ODNI to focus on fulfilling its critical role of serving as the central hub for intelligence integration, strategic guidance, and oversight over the Intelligence Community.”

Coherence across the IC does not mean uniform platforms; it means shared baselines and reciprocal trust. ODNI should establish minimum expectations for red-teaming, continuous monitoring, and auditability. Agencies may deploy different infrastructure, but all systems should still produce logs compatible with a common oversight framework. Shared playbooks for threat detection, standardized reporting of AI incidents, and reciprocal validation of controls would allow the IC to scale innovation while avoiding fragmentation, even as it scales back in size. While ODNI cannot enforce reciprocity for approvals across agencies, it can still establish common frameworks and best practices to ensure a successful adoption of agentic AI across the IC.

Securing the future of AI in the IC

Agentic AI represents a new frontier for builders in the Intelligence Community. But with great autonomy comes greater risk.

The path forward is clear: agencies must adopt secure-by-design environments, integrate AI-aware DevSecOps practices, and enforce controls like boundaries, proxies, and immutable audit logs. Tools such as Coder Boundaries and Coder Tasks provide practical mechanisms to operationalize these safeguards while preserving human accountability and oversight.

ODNI’s role is to provide the ethical and strategic guardrails, but execution must remain federated, managed by each agency in line with its unique mission. The goal is coherence across the IC, not centralization.

Agentic AI is essential. The IC must adopt it boldly but with discipline, within trusted security approaches. The cost of inaction is high: adversaries will not wait. It’s time to move from experimentation to secure execution.

About the Author

Austen Bruhn is the DoD/IC technology strategist and architect at Coder, bringing deep expertise in secure AI adoption and DevSecOps transformation. With experience developing Lockheed Martin’s edge AI systems, deploying Red Hat’s OpenShift classified environments, and now enabling agentic AI workflows for DoD/IC missions, he’s helped agencies navigate the critical imperatives of innovation and security. From hands-on experience from on-orbit Kubernetes deployments to IC-wide AI architectures, Austen focuses on translating federal AI and software development policy into operational reality while maintaining the security posture that national security demands.

About Coder

Coder is the AI software development company leading the future of autonomous coding. Coder helps teams build fast, stay secure, and scale with control by combining AI coding agents and human developers in one trusted workspace. Coder’s award-winning self-hosted Cloud Development Environment (CDE) gives teams the power to govern, audit, and accelerate software development without trade-offs. Learn more at coder.com.

About IC Insiders

IC Insiders is a special sponsored feature that provides deep-dive analysis, interviews with IC leaders, perspective from industry experts, and more. Learn how your company can become an IC Insider.

The post Builders at the Frontline: Safeguarding Agentic AI in the Intelligence Community appeared first on Intelligence Community News.