Not based on a specific customer deployment. The company, figures, decisions, and outcomes below are a constructed example that shows how Intended’s mechanism applies to this kind of problem. They are not measured results from a named customer. Where we publish a real, attributed customer outcome, we will say so explicitly.
Gating Unauthorized Production Deployments by AI Agents
Consider a large engineering org running many daily deployments across dozens of microservices, where AI agents drive CI/CD pipelines, rollbacks, and infrastructure scaling decisions.
01 · the challenge
The kind of problem this addresses.
02 · how it works
See the difference.
Code Push
Build
Test
Intended Gate
Deploy
Monitor
03 · the solution
What they deployed.
- — Started from Intended's code-modification-guardrails policy pack, which escalates production deploys and denies force-pushes and CI-config edits
- — Each deploy workflow has a gate step that calls Intended (SDK or POST /v1/agent-intent) and stops unless the decision is ALLOW or an approved escalation
- — Agents that dispatch GitHub workflows or open ServiceNow change records do it with their own credentials after the ALLOW, carrying the signed token as proof. Intended never holds the team's GitHub or ServiceNow keys
- — Infrastructure scaling calls the same gate through the SDK before the agent changes the cluster with its own credentials
- — Configured thresholds: staging auto-approve, production requires risk < 40 or human approval
- — A signed authority.decision.created webhook lets the team route production escalations into its Slack and PagerDuty alerting
04 · implementation
From zero to governed.
Week 1
Integrate
Add a gate step that calls Intended to each microservice's deploy workflow, and the SDK call to the scaling agent.
Week 2
Configure
Install the code-modification-guardrails pack. Define staging vs. production policies, risk thresholds, and approver roles per team.
Week 3
Simulate
Run policy simulation against recent deploys and tune thresholds until the outcomes match what the teams expect.
Week 4
Enforce
Enable enforcement. Every production deploy now waits for an ALLOW or an approved escalation.
05 · illustrative outcomes
What this is designed to deliver.
Modeled figures for this scenario — what the workflow above is built to achieve, not measured results from a named customer.
0%
Production deploys gated
No deploy without an authority token
0 min
Max token lifetime
Signed and single-use
0%
Deployment decisions auditable
With cryptographic proof
0
Policy tiers
Auto-approve, escalate, deny
06 · decision replay
Example decisions, full trace.
Sample decision records that show the shape of the evidence Intended produces. Illustrative, not drawn from a live customer’s logs.
sdlc.deploy.stagingRISK: 12/100ALLOWDeploy cart-service v2.14.3 to staging environment
Resolved by: Policy: auto-approve staging deployments
sdlc.deploy.productionRISK: 78/100ESCALATEDeploy payment-service v3.8.1 to production (database migration included)
Resolved by: Lead Engineer (approved after review)
sdlc.deploy.productionRISK: 22/100ALLOWDeploy search-service v1.22.0 to production (config change only)
Resolved by: Policy: auto-approve config-only deploys with risk < 40
sdlc.infra.scale-clusterRISK: 65/100ESCALATEScale checkout cluster from 8 to 24 nodes (Black Friday prep)
Resolved by: SRE Lead (approved)
sdlc.deploy.rollbackRISK: 45/100ALLOWRollback inventory-service from v4.1.0 to v4.0.9 (error rate spike)
Resolved by: Policy: auto-approve rollbacks to known-good version
the takeaway
The point of a deployment gate is proof: every production deploy is reviewed against policy before it ships, and that review leaves a signed, auditable record. Authority tokens turn an implicit trust assumption into something an SRE or a CISO can verify.
Why this pattern matters — not a customer quote.
Start governing AI deployments
Free to start. See every AI decision from day one.