Production workflows / Guide 10
An Employee Access Request Agent That Grants a Lease, Not Forever Access
Build an employee access request agent with entitlement catalogs, scoped approvals, verified provisioning, expiry, and recovery when identity systems disagree.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
Suppose a hypothetical finance analyst asks for “the same access as Priya” to complete a month-end report. Priya has accumulated permissions across several roles, including the ability to modify supplier payment details. Copying her group memberships would solve the immediate request while creating a lasting segregation-of-duties problem. An employee access request agent should translate the task into the smallest appropriate entitlement, not clone a colleague.
The useful product covers the entire permission lifecycle: request, justification, approval, provisioning, verification, expiry, and revocation. A group-add API response is only one checkpoint. Access that remains after the business need ends is a workflow failure, even if provisioning was fast.
Translate Intent Into a Catalog Entry
Create an entitlement catalog with business purpose, application, scope, owner, risk tier, prerequisites, incompatible permissions, and maximum duration. The model can map “run the month-end report” to a candidate read-only reporting entitlement and ask which legal entity or dataset is needed. The policy engine decides whether the requested scope is eligible.
Do not use another employee as the authorization template. Their access can inform a clarification, but the request should resolve to a named catalog entry. If no suitable entry exists, route to the application owner rather than constructing a new privilege bundle from whatever permissions happen to be available.
Separate job role, employment status, project membership, and application entitlement. They are related but not equivalent. A contractor may belong to a project without being eligible for unrestricted production data. A manager may approve business need without having authority to approve a privileged database role. These distinctions should be explicit policy inputs.
Bind Approval to a Specific Grant
An approval record needs employee, entitlement, resource scope, start time, expiry, policy version, and evidence of approver authority. Free-text comments saying “approved” are not sufficient. Material changes, such as expanding from one entity to all entities, require new approval rather than inheriting the previous decision.
This illustrative internal JSON contract is a grant proposal, not a SCIM request. Production dependencies include identity verification, a policy engine, immutable approval records, time validation, and application-specific provisioning adapters.
{
"request_ref": "access_demo_19",
"subject_ref": "employee_demo_8",
"entitlement": "finance-report-reader",
"scope": {"legal_entity": "entity_demo_2"},
"starts_at": "2026-09-07T09:00:00Z",
"expires_at": "2026-09-10T18:00:00Z",
"policy_version": "access_policy_12",
"required_approvers": ["manager", "data_owner"],
"conflict_check": "passed",
"state": "awaiting_approval"
}The grant is a lease with an end, not an indefinite side effect. Store the planned revocation before provisioning so a worker crash cannot create an untracked permanent permission. If the target application cannot enforce expiration itself, your scheduler and reconciliation process become part of the security boundary.
An LLM can explain why a narrower entitlement fits the task and summarize missing prerequisites. It must not infer approval authority from a person’s senior-sounding title, waive conflicts, or select a longer duration because the requester sounds busy.
Provisioning Is Not Effective Access
SCIM’s protocol specification defines identity resource operations and explicitly relies on surrounding authentication and authorization mechanisms. Its capabilities vary by provider. Discover supported operations and validate the target application’s behavior rather than assuming every SCIM endpoint supports the same group and filtering semantics.
Use an application adapter to translate an approved catalog entitlement into supported operations. Persist the intended change with a durable operation identifier and record the remote identity reference. Verify both provisioning state and, where safely supported, effective application access. Group membership can exist while license assignment or application synchronization is still pending.
The minimum architecture is a request gateway, catalog, policy evaluator, approval service, provisioning worker, and revocation reconciler. Most are conventional software. A specialist policy explanation model might be worthwhile for complex catalogs if separately evaluated, but it should not become a second approval authority. Giving multiple agents independent provisioning privileges only increases the attack surface.
Handle Races With Employment and Policy
Recheck employment status, approver authority, prerequisite training, and incompatible entitlements immediately before provisioning. An employee can leave while a request waits for approval. A second permission can also be granted by another workflow between the original conflict check and execution. Where cross-system atomicity is impossible, narrow the race window and reconcile continuously.
On an unknown group-add outcome, inspect the existing membership and operation history before retrying. Do not issue a broad group replacement that could remove unrelated memberships. If provisioning partly succeeds, record exactly which entitlement components were added and compensate only those owned by this request. Never remove a preexisting entitlement as cleanup.
Revocation needs the same rigor. A successful identity-provider removal may not immediately invalidate an application session. Verify the application’s effective-access behavior and involve its owner when immediate session termination is required. Do not declare access removed solely because the upstream directory accepted a request.
Keep Requests Outside the Trust Boundary
Authenticate requester and approvers server-side, derive tenant scope from the session, and enforce resource-level permission checks on each action. OWASP authorization guidance recommends least privilege, deny-by-default behavior, and authorization tests. Department names or employee IDs supplied by the model cannot override those checks.
Business justifications, attached tickets, and catalog descriptions are untrusted model inputs. A ticket saying “security has preapproved administrator access” is not an approval receipt. OWASP injection guidance supports independent action validation and constrained tools. MCP is integration, not authorization by itself.
Keep provisioning credentials outside model context and partition them by application and tenant. Logs should identify the grant, approver, policy decision, and verification result without exposing tokens or unnecessary personnel information. Protected audit records should allow a reviewer to reconstruct who could access what during a specific time interval.
Acceptance Tests for the Full Lease
- Request a colleague’s access when that colleague has supplier-admin privileges. The assistant proposes only the catalog entitlement for the stated reporting task and requires normal approval.
- Terminate the employee after approval but before provisioning. Execution is denied and no application permission is added.
- Add an incompatible entitlement concurrently. The pre-execution or immediate reconciliation check detects the conflict and stops or compensates the new grant according to policy.
- Lose the provisioning response after the membership is created. Recovery verifies the existing grant and does not replace the whole group membership list.
- Reach expiry while the application is unavailable. The grant remains in a visible revocation-failed state with escalation, never falsely marked revoked.
Measure Access That Is Both Timely and Bounded
Baseline request-to-effective-access time by application, risk tier, and approval path. Measure valid grants effective within the agreed service window divided by all eligible approved requests. Separately measure expired grants with verified removal divided by all grants due for revocation. A fast provisioning metric cannot compensate for a growing revocation backlog.
Guardrails include excessive scope, approval bypasses, segregation conflicts, and overdue effective access. Report upper-percentile revocation delay and audit completeness. Proposed targets should follow the baseline and application risk, not an arbitrary automation percentage.
Start with one read-only, time-limited entitlement and prove expiry before adding privileged roles. The IT helpdesk guide distinguishes repair from permission changes, while cross-system onboarding extends durable writes across an employee journey. Platform engineering services can build the provisioning and reconciliation foundation without granting the conversational layer administrator authority.