Safe infrastructure automation
Introduce automation to infrastructure safely: bounded scope, tested rollback, approval paths and evidence that each change did what was intended.
What we review
- Current automation inventory: Scripts, scheduled tasks, pipelines and integrations already running, what they touch and who owns them.
- Credential and secrets handling: Where automation credentials live, how they are scoped, rotated and revoked, and whether any hold standing unrestricted access.
- Read-only discovery design: How the environment can be inspected and inventoried safely before any change capability is introduced.
- Change classification: Which operations are safe to automate, which require human approval, and which should stay manual.
- Approval and gating model: How a proposed change is presented, reviewed and authorized before execution.
- Blast radius controls: Batching, staging, rate limits and stop conditions that bound what a single run can affect.
- Rollback and recovery design: How a change is reversed, how the reversal is tested, and how long the window to reverse stays open.
- Evidence and audit trail: What each run records so an operator can reconstruct what happened after the fact.
Deliverables
- Automation inventory and risk register: What exists today, what it can reach, and where unrestricted access is currently held.
- Safety model: Written classification of operations by risk, with the approval required for each class.
- Credential scoping plan: Recommended identities, permissions and rotation approach for automation, with standing access removed where possible.
- Reference workflow: A worked example showing discovery, candidate change, approval, execution and rollback for one real operation in your environment.
- Rollback playbook: The tested way back for the operations in scope, written before the automation is trusted.
- Handover documentation: Enough detail for your team to extend the pattern without re-deriving the safety reasoning.
Engagement boundaries
- Automation reduces repetitive effort and variance. It does not remove the need for someone to understand the systems being changed.
- Read-only discovery is built and validated before any change capability is introduced.
- No automation is granted standing unrestricted administrative access as part of this work.
- Change operations are gated behind explicit human approval unless you direct otherwise in writing, with the risk recorded.
- Rollback paths are written and tested before an automated change is used in production.
- Existing scripts are reviewed and documented, not silently replaced. Replacement is a separate decision.
- Where AI-assisted tooling is in scope, it is treated as an untrusted proposer of changes, not an approver of them.
- Secrets are handled through your existing credential store where one exists. We do not introduce a new secrets location without agreement.
- This work does not certify your automation against any standard or framework.
Questions before the work starts
Will this replace our existing scripts?
Not as a default. Existing automation is inventoried, documented and assessed for risk. Replacing it is a separate decision you make with that information in hand, not something done quietly during a review.
Can automation make changes without us approving each one?
It can, and sometimes that is the right call for low-risk, well-bounded operations. But that boundary is set deliberately and written down, with the accepted risk recorded. The default position is that change requires approval.
Does this involve AI agents?
Only if you want it to. Where AI-assisted tooling is in scope, it is treated as something that proposes changes for review, never something holding unrestricted credentials. The approval gate is the same one a script passes through.
What if the automation makes a mistake?
That is what the blast radius controls and rollback path are for. Batching, stop conditions and a tested way back are designed before the automation is trusted with production work, not added after an incident.
Do you need administrative credentials to do this?
Discovery work is scoped to read-only access wherever the platform supports it. Any elevated access is agreed in advance, time-bounded, and recorded. The engagement boundaries page covers this in more detail.
The platforms this work covers
Automation is built against the management APIs these platforms already expose, with the same approval boundaries on each.
- Microsoft 365 and Entra ID
- Microsoft Azure
- Amazon Web Services
- Cloudflare
- Palo Alto Networks and Panorama
- Fortinet FortiGate
- Check Point
- Cisco
- F5
- Virtualization and data centre platforms
Audits available
- Automation credential audit: what every script, pipeline and integration can reach, and which hold standing access.
Other ways we can help
Engagements are often scoped together; these are the closest neighbours to this one.
Want automation you can actually trust in production?
Describe the repetitive work you want to reduce, what already runs unattended, and what a bad change would cost you. The first conversation is about whether automation is the right answer before it is about how to build it.