In this guide
Who can act?
List the people, service accounts and AI agents that can change the service. Give each one an owner, a reason to exist and a way to switch it off. Start with shared logins and permanent admin rights.
- Can a supplier reach more than the system they support?
- Can an agent reuse a credential outside the task it was given?
What can they reach?
Follow inherited roles, delegated access and links between environments. Test the route to something that matters: a payment, customer data or a production change.
- Which single change would break the route?
- Does the original attack still work after that change?
How do you recover?
Agree which services come back first and what they depend on. Rehearse containment, password and key resets, and checks with the people who would really do the work.
- Who can approve the next recovery step?
- What proof do you need before a service goes live again?
Make it a habit.
Write down the scope, how you tested, what you found and who owns each fix. Look at the critical routes again whenever systems or permissions change.
This is a practical review guide from Riftweld Labs. It isn't a statistics report or a benchmark.