AI agents are already writing detection rules, tuning SIEM settings, and remediating incidents. Veltrix is the stop-gap between them and your production security tools: a non-bypassable pipeline where AI can propose any change — and only a human can promote it.
AI drafts. Humans decide. The pipeline enforces.
Security teams are adopting AI assistants and autonomous agents because the math is irresistible: a copilot can draft a detection rule in seconds, tune noisy alerts overnight, and translate an incident postmortem into configuration hardening before the next standup. The teams that use this well will simply outpace the teams that don't.
But the same properties that make AI useful make it dangerous as an operator. It is confident when it's wrong. It reads attacker-influenced input — logs, tickets, alert descriptions — as instructions. It acts at machine speed across your whole fleet. And when it changes the tools that defend you, a mistake doesn't just break an app: it can silently switch off detection, open access, or drop the logs you'd need to even notice.
Most organizations respond in one of two bad ways: ban AI from operations (and lose the speed), or give an agent broad credentials and hope (and lose the control). There is a third option — the same one engineering solved decades ago for source code: let anyone propose, let machines verify, and let accountable humans merge.
You don't need to solve AI alignment to adopt AI safely in security operations. You need a control plane that makes the safe path the only path. That's what Veltrix is.
These aren't hypotheticals — they're the standard failure modes of giving a language model write access to infrastructure. Each one is survivable with the right choke point in place; each one is a bad week without it.
Security agents read logs, alerts, and tickets — content attackers can influence. A crafted log line or ticket comment can steer an agent into "remediating" its way to a weaker posture: relaxing a role, allowlisting an IP range, or muting the very detection that would catch the intruder.
Models produce configuration that looks right — valid syntax, sensible names — and is quietly wrong: a retention setting that purges evidence, an index pointed at the wrong volume, a role granted a capability it never needed. Plausible-but-wrong is far more dangerous than obviously broken.
To be useful, agents get credentials. Too often they get admin credentials — one identity that can author, approve, and deploy in a single step. Asked to tune one alert, an over-empowered agent can reorganize your entire detection stack, and nothing stands between intention and execution.
Agents retry, loop, and chain. A flawed premise doesn't produce one bad change — it produces fifty, propagated across every environment before a human has finished reading the first diff. Blast radius is a time function, and AI compresses time.
An agent with direct tool access — SSH, a management API, a CLI — changes things without leaving a record in any system you review. Your documented state and your real state diverge silently, and the gap is exactly where incidents live.
When AI and humans share credentials and paths, "who changed this and why?" has no answer. That's an incident-response nightmare and a compliance failure: modern frameworks expect effective human oversight of consequential automated decisions — with evidence.
Don't let your AI agents touch your security tools directly — let them go through Veltrix. An agent holding a tool admin token inherits every privilege of that token, executes instantly, and answers to text it read in a log. An agent holding a Veltrix key can only propose.
Veltrix doesn't try to make the AI trustworthy — it makes trust unnecessary. Agents get exactly one way to affect your security tools: propose a change into a pipeline that validates it, shows a human the exact diff, deploys it progressively, and watches for anything that went around the gate. Read the full argument →
The gate is structural, not procedural. It doesn't depend on the agent being well-behaved, the prompt being well-written, or the model being well-aligned — and it works with any agent framework or model that can call a REST API.
Guardrails only count if you can name what they stop. Here's the mapping.
| AI failure mode | Veltrix control | What it stops |
|---|---|---|
| Prompt-injected or malicious proposal | Mandatory human approval on a field-level diff; per-environment approval policies with minimum approver counts and required roles | A manipulated agent can draft a harmful change, but a human sees exactly what would change before anything touches production |
| Hallucinated configuration | App-defined validation handlers run before a change can even be submitted for approval | Malformed and invalid configs are rejected automatically, so reviewers spend attention on judgment calls, not typos |
| Excessive agency / over-permissive credentials | Role-based access control plus scoped, revocable, expiring API keys; approval is restricted to named human reviewers | The agent's credential can propose; it cannot approve its own work or carry a change to production alone |
| Cascading automation at machine speed | Canary / rolling / blue-green strategies, post-deploy health checks, per-environment error thresholds with automatic rollback, staged environment promotion (staging before prod), and per-tenant rate limits | Even an approved-but-bad change is caught at a fraction of the fleet and rolled back to the last known-good version automatically |
| Shadow changes outside the pipeline | Drift detection compares live tool state against the approved, versioned baseline; critical drift raises a security alert | Out-of-band changes — by an agent, a script, or a person — surface as drift instead of accumulating silently |
| Unattributable actions | Every proposal, edit, review, deployment, and rollback is recorded in versioned history, attributed to a user or an API key | "What did the AI change last Tuesday, and who approved it?" is a query, not an investigation |
| Sneaking changes past a stale review | Re-editing a pending change amends its approval request — like new commits on a pull request, reviewers always see the latest state | No approving version 3 while version 5 quietly ships |
| Untrusted integration code | Tool integrations are open-source apps whose handlers run against a narrow, tenant-scoped, read-only platform data boundary — never the platform database | Even the code that executes changes is least-privileged, reviewable, and shipped through a checksummed, secret-scanned release pipeline |
These are the principles Veltrix is built around. They hold whichever model, vendor, or agent framework you adopt — and they'll still hold when this year's models are replaced by next year's.
Guardrails an agent can route around aren't guardrails. All change — human or AI — flows through the same pipeline, and direct tool access is treated as drift, not as a convenience.
An agent gets the narrowest credential that lets it do its job: scoped, revocable, expiring — and never one that can both author and approve. Separation of duties applies to machines, too.
An AI's summary of its change is generated by the same process that made the mistake. Human oversight only counts when the reviewer sees the exact fields that will change, against the exact current state.
Approval is a judgment; canaries are evidence. Even approved changes earn their way to 100% of the fleet through health checks, error thresholds, and staged environment promotion.
Desired state is only meaningful if you check reality against it. Drift detection turns "the config quietly changed" from an unknown unknown into an alert with a diff attached.
Every change is attributable to an identity — human or API key — with its full before/after history. That's what makes incident forensics fast and audit evidence cheap.
In the AI era you will occasionally approve something wrong — the question is how fast you can undo it. Versioned snapshots and one-action rollback make "undo" a button, not an archaeology project.
A concrete walkthrough: your SOC copilot wants to tighten Splunk role permissions after an incident review.
Model-agnostic by design: anything that can call a REST API — a LangChain agent, an MCP-connected assistant, a nightly script — gets the same guardrails.
Veltrix ships a Model Context Protocol (MCP) server, so Claude Desktop, Claude Code, and any MCP-compatible assistant can connect to your tenant natively — no glue code, no custom integration. The assistant authenticates with a scoped, revocable API key and works through the exact same governed pipeline as everyone else.
The MCP tool surface lets assistants draft canvases, run validation, submit for approval, check pipeline and drift status, and deploy already-approved changes. There is deliberately no approve tool, no reject tool, and no credential access — those stay human, in the portal.
Every MCP session authenticates with a role-bound API key you issue and can revoke at any moment. The key's role decides exactly what the assistant can see and do — a read-only analyst key and a proposal-capable engineering key are one dropdown apart.
Every action an assistant takes through MCP is recorded in the same audit trail as human changes, attributed to the tenant's API identity — so "what did the AI change, and who approved it?" is a query, not an investigation.
Claude Desktop — claude_desktop_config.json
{
"mcpServers": {
"veltrix": {
"command": "node",
"args": ["veltrix-mcp/dist/index.js"],
"env": {
"VELTRIX_API_URL": "https://app.veltrixsecops.com",
"VELTRIX_API_KEY": "vltx_..."
}
}
}
}Read the MCP server documentation →
Veltrix ships the guardrails, not the model: the MCP server connects the AI assistants you already use to the pipeline — Veltrix itself includes no LLM.
Regulators and frameworks are converging on the same requirement: consequential automated decisions need effective, evidenced human oversight. A human-in-the-loop change pipeline is how you demonstrate it for security operations.
Emphasizes effective human oversight of high-risk AI systems — humans able to understand, intervene in, and override automated behavior. Approval gates and rollback are that intervention capability, with records to prove it.
Calls for governing, mapping, measuring, and managing AI risk — including defined human oversight and incident handling. A pipeline that validates, gates, monitors, and reverses AI-initiated change operationalizes the Manage function.
AI management systems require documented controls over how AI is used and supervised in operations. Attributable change records for every AI action provide the documentation trail.
Change management controls don't stop applying because the author is a machine. Versioned approvals, deployment logs, and drift records give auditors the same evidence for AI-made changes as human ones.
Veltrix provides change-governance controls and evidence that support these programs; it does not by itself constitute legal or regulatory compliance.
Give your agents the keys to a proposal queue — not to production. Veltrix puts a human decision, a safety net, and an audit trail between AI and the tools that defend you.