AI-Native DevSecOps: Why Infrastructure Agents Need Governed Change

Your next cloud user may not be human.

It may be an AI agent investigating an incident, correcting infrastructure drift, reviewing a Terraform change, importing an unmanaged resource or preparing a cost-optimisation pull request.

This is already starting to happen. But most cloud operating models were designed around a basic assumption: a human would eventually sit in front of a terminal, interpret the available information and take responsibility for the action.

AI agents break that assumption.

They can operate faster than people, across more systems and for longer periods of time. They can also act with incomplete context, misunderstand an exception or confidently propose a change whose blast radius they cannot see.

That is why AI-native DevSecOps cannot simply mean adding copilots to the existing toolchain.

It requires a new control model for how non-human actors understand infrastructure, receive permissions, propose changes and prove what they have done.

What is AI-native DevSecOps?

AI-native DevSecOps is an operating model in which AI agents participate directly in software delivery, security and cloud operations while remaining subject to enforceable technical controls.

These agents may investigate findings, write Infrastructure as Code, review pull requests, detect drift, propose remediations or execute approved workflows.

The important distinction is that AI-native does not mean AI-controlled.

A serious AI-native DevSecOps system separates probabilistic reasoning from deterministic enforcement:

• The agent can investigate and propose.
• Policies determine what is allowed.
• Validation determines whether the change is technically sound.
• Git records what changed.
• Engineers approve actions where the risk requires judgment.
• Deployment remains inside the organisation’s existing controlled pipeline.

The model may reason. It should not be allowed to define its own boundaries.

The current DevSecOps stack was built for humans

The typical enterprise cloud environment is already fragmented.

Infrastructure intent lives in Terraform, Bicep, Pulumi or CloudFormation repositories. Actual state lives across cloud accounts, Kubernetes clusters and manually created resources. Security findings appear in scanners. Cost recommendations sit in FinOps dashboards. Ownership information is distributed across service catalogues, tickets and Slack conversations.

Humans compensate for this fragmentation.

An experienced platform engineer knows that the Terraform repository is not always the full truth. They remember the emergency console change made two weeks ago, understand why a particular IAM exception exists and know which team must approve a database replacement.

An AI agent does not automatically have that institutional memory.

Giving an agent access to several tools does not solve this problem. It may simply allow the agent to act on several incomplete views at once.

This is the central risk in AI-native DevSecOps: not that the model cannot generate infrastructure code, but that it can generate plausible infrastructure code without understanding the full operational reality around it.

The problem is no longer code generation. The problem is governed change.

Copilots are useful, but they are not an operating model

The first generation of DevOps AI mostly lived inside chat windows and IDEs.

An engineer asked for a Terraform module. The assistant produced a snippet. The engineer inspected it, corrected it and decided what to do next.

This was relatively safe because the assistant had no meaningful authority. It generated text; the human remained the execution layer.

Infrastructure agents are different.

An agent may have access to cloud APIs, repositories, command-line tools, scanners and ticketing systems. It may run for several minutes, make multiple decisions and invoke a sequence of tools before producing an outcome.

At this point, the prompt is no longer an adequate security boundary.

Writing “do not modify production” in a system prompt does not technically prevent the agent from modifying production. Telling it to avoid destructive actions does not remove destructive commands from its toolset. Asking it to request approval does not guarantee that every execution path will stop at the approval gate.

Prompts can guide behaviour. They cannot enforce authority.

The real controls must exist outside the model, in the runtime, permission system, policy layer and change workflow.

The six foundations of governed infrastructure agents

A governed infrastructure agent needs more than an LLM and several integrations. It needs an architecture designed around the possibility that the model will sometimes be wrong.

1. Current infrastructure context

An agent cannot safely manage infrastructure it does not understand.

Repository context alone is insufficient because deployed infrastructure may have drifted from code. Cloud inventory alone is insufficient because it does not explain the intended architecture, module structure or engineering conventions.

The agent needs access to both:

• Live cloud resources and their relationships
• Infrastructure-as-Code repositories
• Module and naming conventions
• Security and compliance findings
• Recent changes and deployment history
• Resource ownership
• Environment criticality
• Relevant policies and exceptions

This context should be machine-readable and current.

An outdated architecture diagram may be useful to a person who knows where it is wrong. To an agent, it may become a confidently incorrect version of reality.

2. A bounded agent runtime

The agent runtime determines how the agent executes tasks, which tools it can invoke, where commands run and when the workflow must stop.

This is where restrictions become real.

A read-only investigation agent should be technically unable to modify files or cloud resources. A remediation agent may be allowed to create a branch and write code while still being prohibited from merging the pull request or applying the change.

The distinction matters.

An instruction tells the agent what it should do. The runtime defines what it can do.

Infrastructure agents should execute in isolated environments, with explicit tool allowlists, timeouts, resource limits and controlled network access. Cloudgeni’s documented trust architecture uses isolated, ephemeral execution environments, credential isolation and scoped access controls around agent workflows.

3. Least-privilege identity

Agents should not borrow a platform engineer’s broad credentials.

Each agent workload should have its own identity, permissions and expiry. Access should be scoped to the task, environment and tools required.

A drift-investigation workflow may need to read cloud configuration and repository state. It does not need deployment credentials.

A remediation workflow may need permission to create a Git branch and open a pull request. It still does not necessarily need permission to merge or apply it.

Short-lived credentials limit the damage caused by a compromised workflow, an incorrect decision or a tool invocation that behaves unexpectedly.

Broad, permanent agent credentials are not an efficiency feature. They are an unmanaged blast radius.

4. Pull-request-first change control

For most infrastructure workflows, the agent should produce a change proposal rather than a direct production action.

That proposal should land in the same place as a human-authored change: a branch and pull request.

This gives the organisation something concrete to review:

• The exact infrastructure diff
• The reason for the change
• The evidence used by the agent
• Validation and policy results
• Expected impact
• Potential replacements or deletions
• Required approvals
• Rollback considerations

Git already provides a mature control surface for infrastructure changes. It includes review, ownership, CI checks, historical evidence and rollback.

There is little reason to throw this away merely because the change was generated by an agent.

Cloudgeni follows this PR-first model: agents connect cloud findings and live state with repository context, validate proposed work and open pull requests rather than deploying changes directly.

5. Deterministic validation and policy enforcement

An LLM can explain why it believes a change is safe. That explanation is not evidence that the change is safe.

Infrastructure changes should pass deterministic checks before they are accepted:

• Formatting and syntax validation
• Static analysis
• Terraform or equivalent plan analysis
• Security-policy checks
• Compliance controls
• Required tag and naming policies
• IAM-risk detection
• Replacement and deletion checks
• Network-exposure rules
• Organisation-specific policies

This creates a clean separation of responsibility.

The model generates a candidate action. Deterministic systems decide whether that action meets the organisation’s rules.

The best infrastructure AI systems will not be those that are never wrong. No probabilistic model can make that promise.

They will be the systems that can be wrong without allowing the mistake to reach production.

6. Complete observability and audit

Traditional application observability asks what the system did.

Agent observability must also help explain why it did it.

Teams need a record of:

• The original request
• Context retrieved by the agent
• Tools invoked
• Credentials requested
• Intermediate decisions
• Policies evaluated
• Approvals received
• Files changed
• Validation results
• Final outcome

Without this trail, an agent failure becomes difficult to reconstruct. The team may see the resulting pull request without understanding which context influenced it or which alternative actions were considered.

Auditability is not just a compliance requirement. It is necessary for debugging and improving the agent itself.

Cloudgeni’s infrastructure-agent architecture treats PR-first change control, least privilege, end-to-end observability and fail-safe behaviour as core design principles rather than optional product features.

Three levels of AI adoption in cloud operations

Most organisations will move through three broad levels.

Level 1: AI assistance

Engineers use AI to explain plans, summarise findings or generate code snippets.

The AI has little authority and the engineer performs the operational work.

This is useful, but the productivity improvement is limited by the amount of manual work remaining after the answer is generated.

Level 2: Disconnected agents

Different tools introduce their own agents.

One agent reviews code. Another analyses cloud security. Another explains observability data. Another identifies cost savings.

Each may be valuable independently, but the organisation now has several agents with separate context, identities, logs, policies and inference costs.

This is where agent sprawl begins.

The organisation has added intelligence to several tools without creating a coherent operating model for non-human infrastructure work.

Level 3: Governed agentic CloudOps

Agents operate across selected workflows through a common control model.

They receive task-specific context and permissions, operate in isolated environments, follow common policies and send changes through the organisation’s existing engineering controls.

This does not require one giant agent with access to everything.

In fact, the safer pattern is usually the opposite: several specialised agents with narrow capabilities and clear escalation paths.

The goal is not maximum autonomy. It is useful autonomy inside explicit boundaries.

What Cloudgeni does in this model

Cloudgeni is an agentic CloudOps platform built around governed infrastructure change.

The platform connects cloud environments and Git repositories so agents can work with live infrastructure state, findings, IaC structure and repository conventions. Proposed changes are analysed and validated before being delivered as pull requests.

The core workflow is straightforward:

1. Connect: Link cloud accounts and Git providers.
2. Import context: Collect resources, findings and repository structure.
3. Analyse: Understand dependencies, policies and team conventions.
4. Validate: Run supported static, policy and plan-style checks.
5. Ship: Open a reviewable pull request with the proposed change and supporting context.

This model can be applied to several recurring infrastructure problems.

Compliance remediation

Security tools are good at generating findings. The unresolved problem is converting each valid finding into a safe infrastructure change.

A Cloudgeni remediation agent can investigate the relevant resource and repository context, prepare the IaC correction, validate it and open a pull request.

The output is not another recommendation for the engineering backlog. It is reviewable work.

Configuration-drift remediation

Drift appears when the live environment no longer matches the declared configuration.

An infrastructure agent can compare cloud reality with repository intent, determine the direction of reconciliation and prepare the required change.

The important part is that the agent does not silently overwrite one truth with the other. It exposes the difference and proposes a controlled resolution.

Importing unmanaged infrastructure

Many organisations have substantial infrastructure created through cloud consoles, scripts or legacy processes.

Agents can discover these resources and help convert them into idiomatic Infrastructure as Code that fits the organisation’s existing modules and conventions.

This gradually brings ClickOps infrastructure back under version control without requiring a large manual migration project.

Infrastructure pull-request review

Agents can review incoming IaC changes for correctness, security, policy and potential operational impact.

This is more useful than generic code review because infrastructure review must reason about what the change will do, not simply whether the code looks clean.

FinOps remediation

Most companies do not lack cloud-cost recommendations. They lack the engineering capacity to investigate and implement them.

An agent can connect cost signals with utilisation, ownership, dependencies and infrastructure code, then prepare a rightsizing, cleanup or policy change for review.

FinOps becomes an execution workflow instead of another dashboard.

Cloudgeni currently documents remediation, drift detection, cloud-resource import, PR review, DevOps-agent and cost workflows within the same Git-based operating model.

Should infrastructure agents ever make direct changes?

Sometimes, but direct execution should not be the default.

There are low-risk, well-understood actions that may eventually justify greater autonomy: restarting a non-critical workload, scaling within predefined limits or executing a thoroughly tested runbook.

Even then, the authority should be narrow.

The right question is not whether an organisation supports human-in-the-loop or full autonomy. That is too simplistic.

The better question is:

Which specific action can this specific agent perform in this specific environment, under which conditions, with which verification and rollback controls?

Autonomy should be granted per workflow, not declared as a general product philosophy.

A production database change and a development-environment cleanup should not have the same approval model.

How to start with AI-native DevSecOps

Do not begin by building a general-purpose autonomous cloud engineer.

Start with one bounded workflow that is repetitive, measurable and already governed by an existing process.

Good starting points include:

• Investigating security findings
• Reviewing Terraform pull requests
• Detecting configuration drift
• Importing unmanaged cloud resources
• Preparing low-risk cost-optimisation changes

Keep the initial agent read-only or PR-only.

Define what it can access, what it cannot access, when it must stop and what evidence it must produce. Run its output through the same CI, policy and review controls used for human-authored changes.

Then measure whether it reduces completed work, not whether it produces impressive demonstrations.

Useful metrics include:

• Findings converted into reviewed fixes
• Time from detection to pull request
• Percentage of agent changes accepted
• Number of corrections required during review
• Engineering hours removed
• Policy violations caught before merge
• Remediations that produced the intended outcome

The objective is not to show that the agent can act.

It is to prove that the organisation can trust the workflow around the agent.

Platform engineering is becoming the control system for machine work

Platform teams have spent years building paved roads for developers.

The next task is building paved roads for agents.

That means defining machine-readable context, identities, permitted tools, policy gates, approval requirements and evidence standards for non-human infrastructure users.

This may become one of the most important responsibilities of platform engineering.

As AI makes it cheaper to generate code and initiate operational work, the scarce capability will no longer be producing another infrastructure change.

It will be determining which changes should be allowed to proceed.

The organisations that understand this will not try to remove governance in order to move faster. They will make governance programmable enough that both people and agents can move quickly inside it.

Frequently asked questions

What is AI-native DevSecOps?

AI-native DevSecOps is an operating model in which AI agents participate in development, security and infrastructure workflows while being controlled through technical policies, scoped permissions, validation, audit logging and approval gates.

What is a governed infrastructure agent?

A governed infrastructure agent is an AI agent whose tools, credentials, actions and change workflows are restricted by systems outside the language model. It can investigate or propose infrastructure changes without receiving unrestricted access to production.

How are infrastructure agents different from DevOps copilots?

A copilot generally assists a human by generating explanations or code. An infrastructure agent can perform multi-step work across repositories, cloud APIs, scanners and other tools. That greater capability requires stronger runtime controls and auditability.

Should an AI agent be allowed to run Terraform apply?

Not by default. The safer architecture is for the agent to create and validate a pull request while deployment remains in the organisation’s existing CI/CD process. Direct execution should be limited to narrow, pre-approved workflows with separate credentials, policies, verification and rollback.

How can AI agents safely change cloud infrastructure?

Safe infrastructure-agent workflows combine current cloud and repository context, sandboxed execution, least-privilege credentials, deterministic policy checks, pull-request-based change control, human approvals for significant actions and outcome verification.

What infrastructure tasks can AI agents perform?

Infrastructure agents can investigate incidents, review IaC, remediate compliance findings, detect configuration drift, import unmanaged cloud resources, prepare FinOps changes and execute bounded operational runbooks.

Does AI-native DevSecOps replace platform engineers or SREs?

No. It changes where their effort is spent. Agents can perform repetitive investigation and prepare technical changes, while engineers define policies, design reliability controls, manage exceptions and make higher-risk decisions.

Govern the action, not just the model

AI-native DevSecOps will not be created by placing a chat interface on top of every infrastructure tool.

It will emerge when agents can do useful operational work without bypassing the controls that make production systems dependable.

That requires current context, constrained runtimes, least-privilege identities, deterministic validation, pull-request-first change control and complete auditability.

Cloudgeni is built around this premise.

The agent investigates and proposes. Deterministic systems validate. Policies constrain. Engineers retain control where judgment and risk demand it.

This may sound less dramatic than promising a fully autonomous cloud engineer.

It is also much closer to what serious infrastructure teams can actually deploy.