AIOps platform
We trust the controls, never the agent.
The Silex AIOps Platform puts AI agents on your level 1 and level 2 operations work. Each agent investigates from a locked-down sandbox with the read access an SRE has, and changes a system only by running a plan a person approved in your ITSM. We call the design zero agent trust: the agent holds nothing that lets it act on its own.
Zero agent trust
Assume the agent can be steered.
Ticket text, alert payloads, tool output, and web pages can all carry instructions an attacker wrote. So the platform never relies on what the agent decides. It limits what the agent can do, in layers that each hold on their own.
Untrusted by design
Everything the agent reads is treated as input an attacker may have written, including the notes earlier runs left in the workflow's memory.
Words never authorize
Approvals come only from a named person in your ITSM, and permissions only from configuration you signed. Nothing the agent writes counts as either.
Constrain effects, not reasoning
The agent investigates freely. What it can reach and change is fixed outside it, so it behaves in production the way it did in testing.
Failure means less change
Permissions, policy, budgets, approvals, and the audit fail closed. No outage gives an agent more power than it had.
Who holds what
The agent holds nothing that lets it act alone.
Every credential, approval, and key that could change a system sits outside the agent's sandbox, with the platform or with you.
The agent holds
Random placeholder keys, not credentials
Two tools, one to find a tool, one to run a short program
The read access an SRE has, through the gateway
A sandbox, removed when the session ends
The platform and you hold
Real credentialsIn the connectors, in AAP, and in your vault
The model provider keyIn the platform's model gateway, which enforces budgets
ApprovalsIn your ITSM, from a named person, read again before every launch
Signing keysHeld only by you; Silex can't widen what an agent may do
The off switchWorks in your data plane, even with the control plane down
Defense in layers
Six layers between the agent and production.
An agent steered past one layer still meets the next. An unapproved change would have to beat all six, starting with your key.
The agent, possibly steered by untrusted input
- Layer 1
Your signed workflow definition
Autonomy, tool grants, and spend caps change only with a definition signed by your key. Silex holds none of your keys.
- Layer 2
The sandbox
No real credentials. The only ways out are the two gateways, through a credential proxy.
- Layer 3
The enforcement gateway
Only the tools the workflow grants, each pinned to the definition you approved. Every call checked and recorded.
- Layer 4
Launch policy
Every Ansible job template classed read-only or change, in policy as code. Read-only templates run under an account that cannot write.
- Layer 5
The change gate and a person's approval
A change runs only as an unrun step of an approved plan. The approval is read from your ITSM again before every launch.
- Layer 6
Ansible Automation Platform and your hosts
Host credentials stay in AAP, under its role-based access and your account policy.
Your production systems
Architecture
Agents work in your network, through two gateways.
A control plane enrolls data planes and shows people what happened. A data plane in your network does all the work that touches your systems and only dials out, so there are no inbound firewall rules to open.
Two planes
The control plane runs in Silex's cloud or your cluster. The data plane runs where your systems are.
Two gateways
Every tool call passes the enforcement gateway and every model call the model gateway, whichever agent runtime runs.
No real credentials in the sandbox
The agent holds placeholders. Only the connectors and the model gateway hold real credentials.
Broad reads, gated changes
The agent reads what an SRE could. It changes a host only through a plan step a person approved.
Run data stays home
Self-hosted or hybrid, transcripts, plans, and the audit stay in your data plane.
Change control
Nothing changes without an approved plan.
The agent proposes, your change process decides, and Ansible Automation Platform runs exactly what was approved.
- 1The agent proposes a typed plan. Each step is checked against launch policy and the inventory, and the plan is stored with its hash.
- 2The change is filed in your ITSM with the plan, under the workflow's own account.
- 3A person approves it there. While it waits, no agent session runs and no sandbox is held, for days if need be.
- 4Before every launch, the gate checks again: the approval in your ITSM, the plan's hash, and the change window.
- 5AAP runs exactly that step, by its id, with the approved hosts and arguments. The job is checked against the commit, its fields, and its result.
- 6The next step runs, or the change stops. A failed check backs out what it found broken before the change closes.
The rule
Any failed check is refused and audited. A launch whose result is lost is never retried. The agent can never approve its own change.
The sandbox
Each agent works sealed inside its own sandbox.
The agent reasons freely. What it can reach and change is fixed outside it, on your Kubernetes or OpenShift cluster.
No real credentials
The agent holds random placeholders. A credential proxy beside it, in its own container, adds the session token on the two gateway routes only and records every refusal.
Two ways out
Egress is denied by default. The model route and the enforcement gateway are the only destinations; the internet and your hosts are blocked.
Locked down
Non-root, a read-only root file system, and no capabilities. The agent's instructions and settings are mounted read-only.
Web research on your terms
Off unless you turn it on. Pages then come through a research proxy that holds each workflow to its allowlist, names itself, and records every URL.
Recorded as it runs
Transcripts and proxy logs leave the sandbox as they are written, so a run is on the record even if it ends badly.
One session, then gone
The sandbox is removed when the session ends, while a run waits on a person, and when the off switch is used.
Every sandbox driver passes the same conformance suite, run from inside the sandbox it checks.
Engineering
What it takes to run agents in production.
Six problems keep AIOps agents in the demo and out of production. Each took a design decision, a build, and tests. More than 13,000 automated tests cover the platform.
Approved isn't what runs
Without it: A change approved for one host runs on every host in the job template.
What we built: Each step runs by its id, fixed as approved, and every job is checked against the plan.
The unconfirmed launch
Without it: The answer to a launch is lost, and a retry runs the change a second time.
What we built: A lost launch is never retried. The platform finds the job, or a person records what happened.
The ticket steers the agent
Without it: An attacker's text in a ticket or a log becomes the agent's next instruction.
What we built: Words never authorize. Only a person approves, and the agent holds no credentials.
Scale overflows the model
Without it: Thousands of job templates and hosts flood the agent's context, and it acts on what it never read.
What we built: Code mode. Short programs filter tool answers inside the gateway, under the same checks, for about a third less model cost.
Tools change after review
Without it: A tool server rewrites a tool's description after review to slip the agent instructions.
What we built: Every tool is pinned by hash. A changed tool is refused until an operator re-pins it, with a reason, on the record.
Agents that lose the thread
Without it: A restart, a provider outage, or a days-long wait for approval wipes out the agent's work.
What we built: Each run is a durable workflow. It resumes from a verified transcript, on a backup model if the first is down, and checks the ticket, approval, and plan again before it acts.
Autonomy
Autonomy is earned on your tickets.
Every workflow starts at Assist. It moves up only on evidence from your own tickets, and only when you sign the change.
- Level 1
Assist
Diagnoses and drafts the fix, and changes nothing. To move up, its findings agree with how your engineers resolved the same tickets.
- Level 2
Act with approval
Applies the change through AAP once your approver approves it in your ITSM. To move up, its changes succeed and it passes our failure scenarios.
- Level 3
Self-heal
Applies, verifies, and closes standard changes while people audit. To stay, it takes no action outside policy, the approved change, or the window.
At Self-heal, a workflow runs the fixes you pre-approved as standard changes without waiting for a person, under the same gate, the same AAP, and the same audit. Every fix is verified, or backed out.
Only your key widens an agent
A promotion, a new tool grant, or a higher spend cap is a new workflow definition. It takes effect only once you sign it with a key you hold, through your CI/CD or the signing tool we provide.
A console user can only draft the request, and the data plane rejects anything unsigned. A compromise at Silex cannot widen an agent.
Stopping is easy: any operator can switch a workflow off, with a reason, and the switch works locally.
Evaluation
Why we built SRE-bench.
Vendor benchmarks don't tell you whether a model can work an operations ticket safely. So we built a lab that looks like an enterprise and put each model and agent harness on call in it.
The lab runs Ansible Automation Platform, ServiceNow change control and CMDB, monitoring and logs, a runbook repository, and a blue-green three-tier application. Its scenarios are failures where the obvious fix is the wrong one, such as a routine patch that quietly breaks the service it lands on.
Graded like a senior SRE
- Did it find the real cause, not just the symptom?
- Did it plan safely, with a health check and a way back?
- Did it follow change control and cite evidence for each conclusion?
- Did it verify the fix before it closed the ticket?
Touching a host directly, or launching without an approved change, voids the run. Runs are graded from platform records, not from what the agent says about itself.
How a new model reaches your workflows
- 1
Our lab
A new model or agent version works our failure scenarios first.
- 2
Your tickets
It runs beside the current version on the same tickets, in Assist, and both are scored.
- 3
Your decision
We report the results. Nothing moves without your sign-off.
- 4
Production
The new version takes over the workflow, under the same controls.
On every live ticket, the agent's findings are compared with how your engineer resolved it. Lab scenarios use synthetic data; none of your data goes to our lab.
Deployment
Three ways to run the platform.
The same images, gateways, controls, and audit in every option. You choose where the planes run and where run data lives.
Full SaaS
Silex runs both planes. Run data is processed and stored in Silex's cloud, isolated per customer.
Hybrid
Silex runs the control plane. The data plane runs in your environment, opens every connection itself, and keeps the run data there.
Self-hosted
You run both planes on your own OpenShift or Kubernetes. The run data stays with you.
- Model calls go only to the route you choose
- The audit goes to your own SIEM
- Your keys sign every change to what agents may do
- People sign in through your identity provider
Built on what you own
Ansible Automation Platform is the trusted execution layer.
Silex is a Red Hat partner. Agents never log in to hosts: every change runs as an approved AAP job template, under its role-based access and policy as code, and lands in the ticket and the audit log.
Your ITSM
Tickets, change records, and approvals stay where they are today. The platform files and reads them as each workflow's own account.
Ansible Automation Platform
The only route for changes. Read-only templates run under an account that cannot write.
Monitoring, logs, and the CMDB
The agent reads them the way an SRE would, through the gateway, with every call recorded.
Your sign-on, vault, and SIEM
People sign in with your identity provider, secrets come from your vault, and the audit goes to your SIEM.
Works with ServiceNow, Red Hat Ansible Automation Platform, OpenShift, GitHub, OpenTofu, Grafana, Prometheus, Loki, CyberArk Conjur, Google SecOps, Claude Code, and Codex.
For your security review
The platform security overview.
A short guide for InfoSec and risk teams: the layers of control, where data goes in each deployment option, how changes are approved, and what happens when something fails.
Or request a demo with your security team.
Questions security teams ask
Questions
Does the agent hold any credentials?
No. The agent holds random placeholders. A credential proxy beside it adds a short-lived session token, bound to that run and workflow, on two routes only: the enforcement gateway and the model gateway. Credentials for your systems stay in the connectors, in AAP, and in your vault.
Can a prompt injection make a change?
It can change what the agent says, not what it can do. A change runs only as a step of a plan a person approved in your ITSM, and the gate reads that approval again before every launch. The agent cannot approve its own change, and nothing it writes counts as authorization.
Where does our data go?
Self-hosted, everything stays in your environment. In the hybrid option, run data stays in your data plane and the control plane keeps only ids, states, and platform metadata. In full SaaS, run data is processed and stored in Silex's cloud, isolated per customer. In every option, model calls go only to the route you choose, and prompts and answers are recorded with secrets redacted.
What can Silex change?
Silex cannot widen what an agent may do. Promotions, tool grants, and spend caps take effect only with your signature, checked against keys you installed. Silex and the control plane hold none of them.
What happens when something fails?
The platform fails toward changing less. Permissions, policy, budgets, approvals, and the audit fail closed, so a change the gate cannot verify is refused. The off switch works in your data plane without the control plane, and a launch whose result is lost is never retried.
Which agent runtimes and models does it use?
Today the agents run in Claude Code and Codex, on models from Anthropic and OpenAI, through the platform's model gateway on your chosen route. The controls live in the gateways, not the agent runtime, so the same rules and audit apply whichever runs.
Next step
See the controls work on a live run.
A demo walks your security and operations teams through the platform with a live run in our lab: a refused launch, a plan filed for approval, and the change it becomes.