# Examples — Access Request & Provisioning Agent

## Standard role-based access, approved → auto-provision (least privilege)

An engineer requests read access to a dev tool their role normally has, with manager approval. Low risk, in-policy.

**Input**

```
Request REQ-5512: engineer requests read access to the staging dashboard. Role policy lists staging:read as standard for engineers. Manager approval present.
```

**Output**

```
{
  "request_id": "REQ-5512",
  "requester_role": "Engineer / Platform",
  "requested_access": "staging-dashboard:read",
  "risk": "low",
  "policy_basis": "entitlement: 'staging:read' is standard for the Engineer role",
  "sod_conflict": "none",
  "approvals": "present (manager approved)",
  "decision": "AUTO_PROVISION",
  "grant": { "access": "staging-dashboard:read", "time_bound": "standing", "applied": true },
  "actions": [ { "tool": "provision_access", "args": { "user": "REQ-5512.requester", "access": "staging-dashboard:read" }, "requires_approval": false } ],
  "requester_note": "Your request for read access to the staging dashboard has been provisioned. It matches your role's standard access and your manager approved it.",
  "escalation": { "needed": false, "to": "none", "reason": "" }
}
```

**Note:** The routine grant the kit clears instantly: read-only, standard for the role, manager-approved, no SoD conflict. It provisions exactly the least-privilege access requested (read, not write) and cites the policy basis. This is the volume that should never need a human.

## Production/admin access requested → never auto-grant, escalate

A developer requests admin access to a production database. Regardless of approval, the high-risk rule forces escalation.

**Input**

```
Request REQ-5570: developer requests admin (write) access to the production payments database, justification 'need to debug an issue'.
```

**Output**

```
{
  "request_id": "REQ-5570",
  "requester_role": "Engineer / Payments",
  "requested_access": "prod-payments-db:admin (write)",
  "risk": "high",
  "policy_basis": "prod:* and *:admin are privileged — not standard for the Engineer role",
  "sod_conflict": "none",
  "approvals": "manager approval present; resource-owner approval NOT present",
  "decision": "ESCALATE",
  "grant": { "access": "", "time_bound": "", "applied": false },
  "actions": [ { "tool": "escalate_to_security", "args": { "to": "security+db_owner", "priority": "high" }, "requires_approval": false } ],
  "requester_note": "Your request for admin access to the production payments database needs security review — production and admin access can't be auto-granted. In the meantime, consider whether time-bound read access or a break-glass procedure would address the debugging need.",
  "escalation": { "needed": true, "to": "security", "reason": "Privileged admin access to a production payments database — high risk, requires security + resource-owner approval; suggest least-privilege/time-bound alternative." }
}
```

**Note:** Even with manager approval and a plausible reason, production + admin access is privileged and high-risk, so it's never auto-granted. The agent escalates to security and the DB owner and proactively suggests a least-privilege alternative (time-bound read, break-glass) — pushing toward minimal access rather than just relaying the request.

## Separation-of-duties conflict → block and escalate

Someone who can already create vendors requests payment-approval access. Granting it would create a fraud-enabling toxic combination.

**Input**

```
Request REQ-5604: a finance ops user with existing 'vendor:create' access requests 'payment:approve' access.
```

**Output**

```
{
  "request_id": "REQ-5604",
  "requester_role": "Finance Ops",
  "requested_access": "payment:approve",
  "risk": "high",
  "policy_basis": "payment:approve is grantable to the role, BUT SoD policy forbids it combined with existing access",
  "sod_conflict": "Requester already holds 'vendor:create'; combining with 'payment:approve' violates SoD (one person could create a vendor and approve its payments)",
  "approvals": "manager approval present",
  "decision": "ESCALATE",
  "grant": { "access": "", "time_bound": "", "applied": false },
  "actions": [ { "tool": "escalate_to_security", "args": { "to": "security+finance_controls", "conflict": "vendor:create + payment:approve" }, "requires_approval": false } ],
  "requester_note": "This request can't be auto-approved: combining payment-approval with your existing vendor-creation access would violate separation-of-duties controls. Finance controls/security will review options (e.g. removing one entitlement or adding a second approver).",
  "escalation": { "needed": true, "to": "security", "reason": "Separation-of-duties conflict: vendor:create + payment:approve on one identity enables fraud; needs controls review." }
}
```

**Note:** The defining control: 'payment:approve' is grantable on its own and the manager approved it — but the requester already holds 'vendor:create', and that combination is a classic fraud-enabling toxic pair. The SoD check catches what a naive entitlement lookup would miss, blocks the grant, and escalates to finance controls with the exact conflict named.
