Role and policy design
Roles scoped to the tasks a service performs, written as code, with wildcard permissions removed and the reasoning recorded alongside each decision.
Security & Compliance
Least-privilege access that is provable, reviewed, and revoked the day someone changes teams.
The work
Standing access accumulates. Roles are granted for one project and never removed, service accounts outlive the service, and a decade later an intern can read the customer database. We design roles around what a workload or person actually needs, then prove it with data from your cloud provider rather than from a spreadsheet.
On the human side we wire single sign-on, enforce multi-factor authentication and federate identity into cloud accounts so there are no separate local users to forget about. Reviews run on a schedule, and a leaver or a team move triggers removal automatically instead of waiting for someone to notice.
Scope
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Roles scoped to the tasks a service performs, written as code, with wildcard permissions removed and the reasoning recorded alongside each decision.
OIDC federation between your identity provider, cloud accounts and CI systems, so workloads assume short-lived roles instead of holding access keys.
Central authentication with phishing-resistant factors where available, conditional access for risky sessions, and group membership driving permissions rather than manual assignment.
Recurring review cycles with the evidence attached: what each identity can do, when it was last used, and who is accountable for confirming it is still needed.
Joiner, mover and leaver events from your identity provider remove or adjust access within minutes, closing the gap between someone leaving and their permissions disappearing.
A view of who can reach what, generated from the cloud APIs and refreshed on a schedule, so access questions get answered from data rather than recollection.
What changes
Handover
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
Tooling
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
How it runs
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
We pull the real permission data from every cloud account and identity provider, then compare it against what the workload or person is supposed to do.
Roles are rebuilt from usage evidence, and anything that cannot be scoped safely yet gets a documented temporary exception with an expiry date.
Identity providers are connected, local users are retired and break-glass accounts are separated, tested and stored somewhere a person cannot casually use them.
The review cycle starts with a named owner per application, and joiner-mover-leaver automation is tested with real leaver events before anyone relies on it.
Questions
It can if a role was quietly covering for something undocumented, which is exactly why we build roles from observed usage rather than from the existing policy. Changes ship with monitoring first, so an application that loses a permission it actually uses shows up quickly.
No, and moving in one step is usually a mistake for a large estate. We connect the highest-value systems first, leave local accounts alive with a documented expiry date, and migrate the rest in waves.
Secrets work is about what an application holds. This is about what an identity is allowed to do and for how long. They meet at federation, where a workload proves who it is and receives a short-lived credential, but the reviews and the deliverables are different.
The application owners do, and that is deliberate. We set up the process, the tooling and the first two cycles with you, and the reporting is designed so a team lead can complete a review in a few minutes rather than an afternoon.
Security & Compliance
No credentials in Git, no shared password spreadsheets, and automatic rotation you never have to think about.
Continuous evidence collection instead of a quarterly fire drill — audit trails generated by your pipeline.
Well-architected landing zones and migrations that move workloads without moving your risk profile.
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.