Home · Solutions · Other solutions
Solution · Other solutionsOne catalogue, one policy table, and a grant that expires without anyone remembering it
Engineers get cloud and repo access within the hour, scoped
Engineers request access from a catalogue in Microsoft Teams; a policy table grants routine scopes at once, robots execute the grant in GitHub, Azure, AWS and Snowflake, and every grant expires.
Executive summary
Six days waiting for a repository, and a personal access token pasted into a chat to keep the sprint moving.
The first thing we build is a front door: one catalogue of engineering resources in the language engineers use.
Routine access arrives within the hour, so the reason to borrow a colleague's token disappears.
GitHub; Microsoft Azure subscriptions and Kubernetes clusters; AWS accounts
Business problem
Engineering
Engineering access is spread across systems that were never designed to share an approval model. Azure roles can be made eligible in Microsoft Entra Privileged Identity Management. GitHub teams are managed by whoever holds organisation owner. AWS roles sit in a separate account structure, the data warehouse has its own grants, and the Kubernetes clusters have theirs.
Almost every real request touches several at once, so it becomes a ticket for the platform team, whose engineers also build the platform. Approvers are unclear, so requests wait while somebody works out who should decide. Durations are never set, so grants accumulate until a quarterly review asks a tech lead to judge four hundred role names in one sitting.
Engineers who are waiting work around the process, and the workaround is always less secure than the process would have been. It survives because the platform team is measured on uptime and delivery rather than on the queue, and because nobody owns access as a product.
How it works today
- PersonAn engineer raises a Jira ticket describing in free text the repository, environment or cloud role they need
- WaitingThe ticket queues with the platform team, who triage between incidents and platform work and often ask for clarification
- PersonThe approver is guessed from the team name and chased in a chat thread until somebody answers
- WaitingDays pass; the engineer borrows a colleague's token to keep the sprint moving
- SystemA platform engineer grants in GitHub, then in the Azure portal, then in the warehouse, one console at a time
- Risk of errorThe ticket closes with no end date, so the grant survives the project, the team change and the reorganisation
- Risk of errorMonths later the access review asks a tech lead to certify four hundred role names, and everything is approved
Why the current process costs more than it appears
The bill that never reaches the budget.
- Platform engineers at the top of the pay scale spend hours a week on clerical grants, the least valuable work the company can buy from them.
- Waiting has its own price: the requesting engineer loses context around every pause, and the borrowed token is a cost in no budget line.
- Standing privileges grow with every grant that never expires, so the reach of one compromised account widens quietly.
- Reviewers cannot judge what they did not scope, so the quarterly review certifies the accumulation instead of correcting it.
- Forgotten sandbox subscriptions keep billing, onboarding takes a week longer than it should, and every acquired team arrives with another set of consoles.
Cost of inaction
Volume here follows hiring and architecture: every new service, cluster and cloud account adds request types, and the platform team grows more slowly than either. Time to grant lengthens, and the workaround spreads from two tech leads to the norm.
The second cost compounds instead of repeating. A grant made without an end date in March is still live in December, and everything never removed is the reach of one leaked token, which for a payments company means a conversation with a regulator. Sandbox subscriptions keep billing meanwhile, and engineers who join expecting self-service draw their conclusions in the first week.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A payments software company with 380 engineers; the products run on Microsoft Azure with some services on AWS, code in GitHub, pipelines in Azure DevOps, analytics in Snowflake and workloads on Kubernetes. Microsoft Entra ID P2 is licensed, with Privileged Identity Management configured for Azure subscription owner roles only.
About 520 access requests a month reach a platform team of six as Jira tickets: repository and team membership, non-production environment roles, production read roles, temporary production admin, cloud subscriptions for experiments.
Free-text tickets, an approver guessed from the team name, execution by hand across several consoles, and a ticket closed without an end date. The median time to grant is just over two days.
Around 24 minutes of platform engineer effort per request across triage, approver hunt and execution, plus roughly 20 minutes the requesting engineer loses to context switching while the ticket sits.
A catalogue of engineering resources behind a request card in Microsoft Teams; a policy table that grants routine scopes on the spot and routes the rest to a named approver; robots that execute the grant where the access lives; a register of requester, approver, scope and expiry; and a scheduler that revokes when the time runs out.
Routine access arrives within the hour, three requests in four never reach a platform engineer, and standing privilege stops growing because every grant carries an end date. Illustrative, not a client result.
Proposed solution
The first thing we build is a front door: one catalogue of engineering resources in the language engineers use, from a repository and a non-production environment role to a production read role, a warehouse role and a cloud subscription for an experiment. An engineer opens a request card in Microsoft Teams, picks the item, states the scope and accepts or shortens a default duration. Free text becomes a choice, and the choice makes everything after it decidable.
The second is the decision. Security writes a policy table, held as DMN business rules in UiPath Maestro, and no rule lives anywhere else. Non-production read for a member of the owning team is granted on the spot. Production read needs the tech lead, who approves from a UiPath Action Center task inside the same Teams client. Production write or admin needs the tech lead and security, and is issued as a time-bound activation in Microsoft Entra Privileged Identity Management or an equivalent short-lived role. Nobody approves their own.
The third is execution and a clock. UiPath Robots grant where the access lives: Azure RBAC and PIM assignments through Microsoft Graph, AWS and Snowflake roles through their connectors in UiPath Integration Service, GitHub team membership through a connector we build on the GitHub REST API. Each grant is read back from the target system and written to UiPath Data Fabric with requester, approver, scope and expiry, and a time trigger in UiPath Orchestrator revokes it when the date passes, after a renewal card. Power BI reports time to grant by scope, standing privileged grants and what expires this week. No AI in the path: an access decision has to be readable line by line a year later.
Microsoft Entra Privileged Identity Management eligible roles with time-bound activation, approval and audit history; Azure RBAC; Microsoft Entra ID Governance access packages; UiPath Maestro BPMN with DMN business rules; UiPath Action Center tasks completed inside Microsoft Teams; UiPath Orchestrator time triggers, credential stores and audit log; UiPath Data Fabric entities with audit
The resource catalogue, the policy table, the request and approval cards, an execution robot per target system with read-back, the grant register, the expiry and renewal scheduler, the exception queue and the Power BI report
GitHub team and repository membership through a Connector Builder connector on the GitHub REST API; AWS IAM and Snowflake roles through their UiPath Integration Service connectors; Azure RBAC and PIM assignments through Microsoft Graph
How the automated process works
- PersonAn engineer opens the request card in Microsoft Teams, picks a catalogue item, states the scope and accepts or shortens the duration
- AutomationThe policy table evaluates requester, team, resource and scope, and separates what it grants from what needs a person
- AutomationA routine scope, non-production read for a member of the owning team, is granted within minutes and confirmed in the same chat
- PersonEverything else reaches the approver the catalogue names as an Action Center task in Teams: the tech lead for production read, security as well for privileged scope
- SystemA robot executes the grant in the target system, reads the result back, and writes requester, approver, scope and expiry to the register
- AutomationBefore the expiry a renewal card reaches requester and approver; without a renewal the scheduler revokes the grant and records the removal
- PersonA failed grant, or a request fitting no catalogue item, becomes a task for the platform team, who decide and add the item when it recurs
Human-in-the-loop model
Automation handles
- Evaluating every request against the policy table and granting the routine scopes at once
- Routing the rest to the approver the catalogue names, and chasing them in Teams
- Executing and reading back grants in GitHub, Azure, AWS and Snowflake, and registering each one
- Sending renewal cards and revoking the grants whose time has run out
People decide
- Tech leads approve production read for their own teams and decide on renewals
- Security owns the policy table and approves every privileged scope
- The platform team handles failed grants and decides which exceptions become catalogue items
- Engineering management reviews standing privilege once a month
Before and after
Systems and integrations
Every entry can be checked in vendor documentation. The evidence class is stated next to each one.
Inputs
- request cards from Microsoft Teams
- the resource catalogue
- the policy table owned by security
Automation layer
- UiPath Maestro
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
- UiPath Data Fabric
Target systems
- GitHub
- Microsoft Azure subscriptions and Kubernetes clusters
- AWS accounts
- Snowflake
- Azure DevOps
- Microsoft Entra ID with Privileged Identity Management
Human touchpoints: the request card in Teams; approval tasks in UiPath Action Center; renewal cards before expiry; the platform team's exception queue
Technologies used
eligible roles activated for a set time with approval, justification and audit history
Aaccess packages for group-based scopes, with approval stages and assignments that end by themselves
Athe policy table: who may request what, what is granted at once and who approves the rest
Aexecution in each target system with read-back; time triggers for expiry and revocation; credential store and audit log
Agrants in AWS IAM and Snowflake, Azure management calls, Teams messages, and a custom connector on the GitHub API
Aapproval and exception tasks completed without leaving the chat client
Athe grant register: requester, approver, scope, expiry, renewal and revocation, with audit
Atime to grant by scope, share granted within policy, standing privileged grants and expiries due
AIllustrative economic model
The arithmetic is open, so it can be argued with.
Only the platform team's own work is in the calculator, and only the part a policy table can take: three requests in four of the 520, at the 24 minutes each costs in triage, approver hunt and execution across consoles, and €82 an hour fully loaded for a platform engineer. The requesting engineer's 20 minutes per request sit in the next section. Licences, forgotten sandbox subscriptions and the security value of removing shared tokens stay outside the arithmetic, and the last of those is usually why a CISO sponsors the work.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Routine access arrives within the hour, so the reason to borrow a colleague's token disappears
- Every grant carries an end date enforced by a scheduler, so standing privilege stops accumulating between clean-up projects
- Approvers are named by the catalogue instead of guessed from a team name, so nothing waits for the wrong person
- Platform engineers stop executing grants by hand across five consoles and go back to the platform they are measured on
- The access review shrinks to the grants that were renewed on purpose, with scope, approver and date already recorded
- Onboarding a team, or an acquired company, becomes catalogue entries rather than tribal instructions
The management view
- Time to grant becomes a measured number per resource type, so a slow approver is visible rather than suspected
- Standing privileged grants have a trend line, and its direction is the control a board actually asked for
- The register answers who holds what, granted by whom and until when, in one query
- The platform team's queue turns into a list of exceptions, so its capacity can be planned rather than absorbed
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- Each execution robot holds one narrow right per system: a GitHub app limited to team membership, an Azure role assignment right bounded by the catalogue's role definitions, an AWS role restricted to the listed IAM roles, a Snowflake role bounded the same way
- Privileged scopes are never standing: they are Privileged Identity Management activations or short-lived roles whose end time the scheduler enforces, stored beside the approval that granted them
- The policy table belongs to security, is versioned and changes only through a reviewed release; nobody approves their own request, and the emergency route is recorded as one
- Robot secrets are resolved at run time from Azure Key Vault through the Orchestrator credential store, and each grant, read-back and revocation is a separate record
- Processing stays inside your Microsoft 365 tenant and the EU region of UiPath Automation Cloud; the register carries identifiers, scopes and dates, never code or data from the granted systems
Why now
Regulation of financial software, DORA included, treats privileged access as something to be evidenced rather than described, and a register of grants with approver and expiry is that evidence
Privileged Identity Management and Azure RBAC provide time-bound, approved activation natively for the Microsoft estate, so what remains is the wrapper around GitHub, AWS and the data platform, and connectors make that wrapper configuration
Engineers expect platform self-service and vote with workarounds when they do not get it; the modelled €12,792 a month of platform handling continues meanwhile, and so do the borrowed tokens
Relevant executive roles
Engineers are unblocked within the hour without weakening control, and the platform team builds instead of granting
Shared tokens lose their reason to exist, privilege expires by default, and every grant carries its approval
Onboarding a team or an acquired company becomes catalogue entries rather than tribal knowledge
One access process across code, cloud and data, with a register to query instead of five consoles
Common questions and objections
For Entra roles and Azure RBAC it does, and we use it underneath rather than around it. The same request still becomes a ticket for GitHub, AWS, Snowflake and the cluster; the catalogue, the policy table and the register cover all of them.
The form is a Teams card with an item, a scope and a duration, answered in minutes. What they resent is the six-day ticket, which is why they route around it.
Only inside a policy table security wrote, and only for the scopes it named: non-production read for a member of the owning team. Everything else keeps a named approver, and every grant now expires, which is more control than today.
When this is not the right solution
- Fewer than about fifty engineers on a single cloud, where Privileged Identity Management and a well-kept GitHub team structure already answer the question
- An internal developer platform already offering self-service access; then the useful work is the register and the expiry, not a second front door
- No appetite in security for writing a policy table; without it every request stays a human decision and the queue stays where it is
A question for the next management meeting
If we asked three of our tech leads today whether they have ever shared a token to unblock a colleague, how many would say yes, and what would that tell us about the distance between our access process and our written security policy?
Implementation approach
Delivery runs in stages, so it can be stopped at any point.
We deliver
- Classification of the last quarter of access tickets into catalogue items, with the share a policy would have granted
- The policy table drafted with security and two engineering leads: scopes, approvers, durations, and what counts as routine
- Request and approval cards in Microsoft Teams, and the exception queue for the platform team
- Execution robots per target system with read-back, starting with GitHub and non-production Azure
- The grant register, the renewal cards, the revocation schedule and the Power BI report on time to grant and standing privilege
- Shadow-mode testing against real requests, documentation, and training for tech leads and the platform team
We need from you
- API access to each target system, with an account per system scoped to the catalogue's roles
- Microsoft Entra ID P2 or Microsoft Entra ID Governance for the privileged scopes, and a security owner for the policy table
- A named approver per catalogue item, and the last quarter of access tickets from Jira
Stages
Discovery
Last quarter's tickets classified; catalogue items and a first policy table drafted with security
Design
Scopes, approvers, default durations, the register schema and the security model
Pilot
GitHub and non-production Azure for two teams, beside the ticket queue, auto-approval limited to non-production read
Validation
Real requests replayed in shadow mode; grants, read-backs and revocations tested
Scale
Production scopes through Privileged Identity Management, then AWS, Snowflake and the remaining teams
Run
Monthly review of standing privilege, catalogue changes, and the exception queue as the backlog
Departmental. Effort follows the number of target systems and the quality of their APIs, how much of the policy security will write down, and whether an approver can be named per catalogue item rather than per team.
A token pasted into a chat is faster than our access process, and it never expires.
Show us your access-request form and the last fifty requests your platform team handled. We return a draft policy table marking which would have been granted within the hour and which time-boxed.
Draft your policy table with usThe neighbouring process usually has the same problem
A third of your resources have no owner, so the invoice is explained with a screenshot of a chart.
View solution IT & servicesAccess requests and quarterly access reviewsManagers sign off on entitlements they cannot read, and nobody withdraws what nobody uses.
View solution Other solutionsAdmin rights that exist only for the task and the hourRights granted for a four-hour task stay for a career, in systems that cannot expire them.
View solutionIndustries we deliver this in most oftenServices & ITFinance & insurance