{"slug": "access-request-provisioning-agent", "title": "Access Request & Provisioning Agent", "summary": "AgentKit released the Access Request & Provisioning Agent, an open-source blueprint under Apache-2.0 that validates access requests against policy, separation-of-duties, and risk scoring before provisioning or escalating. The agent enforces least privilege by default, blocks toxic combinations, and never auto-grants sensitive access, instead escalating exceptions with a full audit trail. It is governed by the AgentAz specification, which documents trust levels, tool boundaries, and human handoff triggers for security review.", "body_md": "## Overview\n\nValidate → policy-check → SoD → risk-score → provision or escalate: turns an access request into a safe, policy-grounded outcome.\n\nLeast privilege by default: it grants only the standard, low-risk access a role clearly warrants, and nothing more.\n\nSeparation-of-duties aware: it blocks grants that would create a toxic combination (e.g. create-vendor + approve-payment).\n\nDefensive: never auto-grants privileged/production/sensitive access, prefers time-bound grants, and escalates exceptions with a full audit trail.\n\n## AgentAz™ specification\n\nA lightweight, design-time governance spec for security review. It documents what this agent is authorized to do — and why — and pairs with whatever policy engine you already run. It does not enforce anything at runtime.\n\nMachine-readable contract (`agentaz.json`\n\n), validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL:\n\n```\n{\n  \"$schema\": \"./agentaz.schema.json\",\n  \"version\": \"2.0.0\",\n  \"last_reviewed\": \"2026-06-24\",\n  \"agent_id\": \"access-request-agent\",\n  \"trust_level\": \"A3\",\n  \"dna_pattern\": \"Planning\",\n  \"worst_case_action\": \"Prepares an incorrect access change for human approval. Cannot grant or revoke access.\",\n  \"authority_boundary\": \"Prepares access changes against policy for approval; provisioning tools absent.\",\n  \"tags\": [\n    \"security\",\n    \"iam\",\n    \"access-request\",\n    \"human-approval\"\n  ],\n  \"tool_boundary\": {\n    \"allowed_tools\": [\n      \"read_request\",\n      \"check_policy\",\n      \"prepare_change\",\n      \"summarize\"\n    ],\n    \"execution_tools_absent\": true\n  },\n  \"output_boundary\": {\n    \"format\": \"structured_json\",\n    \"never_emits\": [\n      \"grant_access\",\n      \"revoke_access\",\n      \"provisioning_write\"\n    ]\n  },\n  \"cost_boundary\": {\n    \"max_usd_per_trace_loop\": 0.25,\n    \"alert_threshold_usd\": 0.16\n  },\n  \"loop_boundary\": {\n    \"max_reasoning_turns\": 8\n  },\n  \"human_handoff\": {\n    \"triggers\": [\n      \"sensitive_resource\",\n      \"policy_ambiguous\",\n      \"low_confidence\"\n    ],\n    \"destination\": \"access_owner\"\n  },\n  \"audit\": {\n    \"append_only\": true,\n    \"logs\": [\n      \"request\",\n      \"policy_check\",\n      \"prepared_change\",\n      \"approvals\"\n    ]\n  }\n}\n```\n\nNew to this? Read the [AgentAz specification guide](/agentaz-specifications) — Trust Levels, DNA patterns, and how it complements your runtime.\n\nThis is a **flagship reference blueprint** for AgentAz v1.0.0. AgentAz™ is open source under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0) (spec text under CC‑BY‑4.0) — schema and source on [GitHub](https://github.com/agent-kits/agentaz).\n\n## Governance matrix\n\nA scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality.\n\n| Agent goal | Bounded by the authority spec above |\n|---|---|\n| Trust Level | A3 — Human-Approved |\n| Tool access | Least privilege — execution tools absent (read-only) |\n| Context handling | Grounded in provided inputs; cites or flags rather than guessing |\n| Memory strategy | Task-scoped; no persistent cross-session memory |\n| Human approval | Required on sensitive resource, policy ambiguous, low confidence → access owner |\n| Audit trail | Append-only log (request, policy check, prepared change, approvals) |\n| Cost & loop bounds | ≤ $0.25 per loop · ≤ 8 reasoning turns |\n| Recovery / escalation | Escalates to access owner |\n\n## Agent component mapping\n\nA framework-neutral view of how this blueprint maps to standard agent-architecture components (the vocabulary common to ADK-style frameworks). It describes structure for clarity — not an official integration or certified compatibility.\n\n| Agent | Primary reasoner — Human-Approved authority (A3) |\n|---|---|\n| Tools | read request, check policy, prepare change, summarize — execution tools absent (read-only) |\n| Memory | Task-scoped working context; no persistent cross-session memory |\n| Guardrails | Worst-case classified (A3); no execution tools; ≤ $0.25/loop · ≤ 8 turns |\n| Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned |\n| Handoff | Escalates to access owner on sensitive resource, policy ambiguous, low confidence |\n\n## Failure modes\n\nSpecific ways this blueprint can fail, and how it is designed to detect, contain, and recover from each — the boundaries that make it safe to run, stated plainly.\n\nPrepares an over-privileged grant — more access than the request needs.\n\n- Detection\n- The request is compared to a role baseline; privilege escalation is flagged.\n- Mitigation\n- The agent prepares only; a human approves, with a least-privilege check.\n- Recovery\n- The approver rejects it and a right-sized grant is prepared.\n\nDecides against a stale policy.\n\n- Detection\n- The policy version is checked at decision time.\n- Mitigation\n- Access is never granted autonomously.\n- Recovery\n- The request is re-evaluated against the current policy.\n\nA segregation-of-duties conflict slips through.\n\n- Detection\n- A segregation-of-duties ruleset is checked and conflicts are flagged.\n- Mitigation\n- Conflicts are flagged for a human and never auto-approved.\n- Recovery\n- The case is routed to the access owner; it is denied or the exception is logged.\n\n## Evaluation\n\nLeast-privilege correctness matters most — whether the prepared grant matches the minimal access the request warrants — because over-provisioning is the silent risk.\n\n| Decision agreement | Agreement of the prepared grant or deny with an access owner's decision. |\n|---|---|\n| Least-privilege accuracy | Share where the proposed scope matches the minimal necessary, with no over-provisioning. |\n| SoD-conflict recall | Of segregation-of-duties conflicts present, the share it flags. |\n| Escalation rate | How often it correctly routes exceptions to a human. |\n| Latency | Time to a prepared decision. |\n\n**Recommended approach.** Replay historical access requests with known correct outcomes and role baselines; measure agreement, over-provisioning rate, and SoD-conflict recall. Approvals always remain human during evaluation.\n\n## When to use\n\nUse it when\n\n- Your IT/helpdesk queue is full of routine access requests that follow role-based policy.\n- You have an entitlement/role policy and identity data (role, department, manager) the agent can check against.\n- You want consistent least-privilege provisioning with separation-of-duties enforcement and a clean audit trail.\n- You want to auto-handle standard low-risk grants while routing privileged and sensitive ones to humans.\n\nAvoid it when\n\n- You expect it to grant admin, production, or sensitive-data access autonomously — it must not.\n- You have no role/entitlement policy for it to ground decisions in.\n- You can't integrate approval verification, so it would have to assume approvals.\n- You can't keep human review on privileged and exception requests.\n\n## System prompt\n\n```\nYou are an Access Request & Provisioning Agent in an IT/security workflow. You process ONE access request: validate it, check policy, enforce least privilege and separation-of-duties, and either provision standard low-risk access or escalate. You are judged on safe, correct, least-privilege provisioning and on never granting access that should have gone to a human.\n\n== CORE PRINCIPLES ==\n1. Least privilege by default. Grant the minimum access the person's role clearly warrants for the stated need — never more. Prefer time-bound / just-in-time grants over standing access.\n2. Policy-grounded. Base every decision on the entitlement/role policy and verified identity data (role, department, manager). Cite the policy basis. Do not invent entitlements.\n3. Verify, don't assume. Confirm the required approvals and justification actually exist. Never fabricate or presume an approval.\n\n== HARD RULES (NON-NEGOTIABLE) ==\n- NEVER AUTO-GRANT HIGH-RISK ACCESS: Admin/privileged roles, production system access, sensitive/regulated data, security tooling, or anything outside the requester's standard role MUST be escalated for human approval — never auto-provisioned.\n- SEPARATION OF DUTIES: Block any grant that creates a toxic combination (e.g. create-vendor + approve-payment, develop + deploy-to-prod, request + approve). Flag the conflict and escalate.\n- APPROVAL REQUIRED WHERE POLICY SAYS: If policy requires manager and/or resource-owner approval, verify it's present before provisioning. Missing approval = escalate, not grant.\n- AUDIT EVERYTHING: Every decision (grant or deny) is logged with the policy basis, approvals, and risk rationale.\n- NO FABRICATION: Never invent an entitlement, role, approval, or justification. If data is missing, request it or escalate.\n\n== METHOD ==\n- Validate the request and resolve the requester's identity (role, dept, manager).\n- Look up the entitlement policy for the requested access; determine if it's standard for the role.\n- Run a separation-of-duties check against the requester's existing access.\n- Score access risk (privilege level, data sensitivity, production scope, blast radius).\n- Verify required approvals. Then decide.\n\n== DECISION POLICY (calibrated confidence 0.0-1.0) ==\n- AUTO_PROVISION: standard, low-risk, role-appropriate access; no SoD conflict; required approvals present; confidence >= 0.85. Grant least-privilege (time-bound if supported).\n- REQUEST_INFO: missing justification or approval — state exactly what's needed; do not grant.\n- ESCALATE: privileged/production/sensitive access, SoD conflict, out-of-role request, or any uncertainty. Route to security/owner with the findings.\n\n== COST CONTROL ==\nLook up only the policy and identity data this request needs; reuse what's loaded. Cap tool calls; if exceeded, escalate with current findings.\n\n== OUTPUT FORMAT (return ONE JSON object) ==\n{\n  \"request_id\": \"<id>\",\n  \"requester_role\": \"<role/dept>\",\n  \"requested_access\": \"<resource + level>\",\n  \"risk\": \"low|moderate|high\",\n  \"policy_basis\": \"<entitlement rule cited>\",\n  \"sod_conflict\": \"<conflict description, or 'none'>\",\n  \"approvals\": \"<present/required/missing>\",\n  \"decision\": \"AUTO_PROVISION|REQUEST_INFO|ESCALATE\",\n  \"grant\": { \"access\": \"<least-privilege grant>\", \"time_bound\": \"<expiry, or 'standing'>\", \"applied\": <bool> },\n  \"actions\": [ { \"tool\": \"<tool>\", \"args\": { ... }, \"requires_approval\": <bool> } ],\n  \"requester_note\": \"<clear status message>\",\n  \"escalation\": { \"needed\": <bool>, \"to\": \"security|resource_owner|manager|none\", \"reason\": \"<why, or empty>\" }\n}\nIf access is privileged/production/sensitive, or any SoD conflict exists, decision must be ESCALATE — never AUTO_PROVISION.\n```\n\n## Simulate run\n\nTry the agent with a sample task. This is a frontend-only preview that shows how the kit would plan and execute — no API calls, nothing leaves your browser.\n\nFrontend preview only — no data leaves your browser. Tip: press `⌘/Ctrl` + `Enter` to run.\n\n## Setup guide\n\nInstall and connect IAM/ITSM\n\nInstall the agent and connect it to your identity provider and ticketing.\n\n```\npipx install access-request-agent\naccess-request-agent connect --idp okta --itsm servicenow\naccess-request-agent doctor   # verifies least-privilege provisioning scope\n```\n\nConfigure guardrails\n\nWhat may auto-provision. Privileged/sensitive/production access never can. Enforced outside the model.\n\n```\ncp .env.example .env\nANTHROPIC_API_KEY=sk-ant-...\nAUTO_PROVISION_ONLY: { risk: \"low\", role_standard: true, approvals: \"present\" }\nNEVER_AUTO: [\"admin\", \"production\", \"sensitive_data\", \"security_tooling\"]\nPREFER_TIME_BOUND=true\n```\n\nLoad entitlement policy & SoD rules\n\nDefine standard role entitlements and the toxic combinations to block.\n\n```\n# access.yml\nroles:\n  engineer: { standard: [\"repo:read\", \"ci:read\", \"dev-db:read\"] }\nsod_conflicts:\n  - [\"vendor:create\", \"payment:approve\"]\n  - [\"code:develop\", \"prod:deploy\"]\nprivileged: [\"*:admin\", \"prod:*\", \"pii:*\"]\n```\n\nDry-run on past requests\n\nReplay historical requests to confirm it never auto-grants privileged access or SoD conflicts.\n\n```\naccess-request-agent backtest --range 60d --explain\n# reports auto-provision/escalate decisions; privileged auto-grants must be 0\n```\n\nWire into the request flow\n\nRoute access requests to the agent; privileged/sensitive/SoD requests auto-route to security.\n\n``` php\n# access request ticket -> POST https://your-host/access/handle (HMAC)\n# decision=ESCALATE auto-assigns to the security queue\n```\n\n## Architecture\n\n## Tools required\n\n## Workflow\n\n1. Validate the request\n\nCapture the requester, resource, level, and justification, and resolve identity (role, dept, manager).\n\n2. Check entitlement policy\n\nLook up the role-based policy for the requested access and determine whether it's standard or an exception.\n\n3. Run separation-of-duties\n\nCompare against existing access for toxic combinations; a conflict blocks auto-provisioning.\n\n4. Score access risk\n\nRate privilege, data sensitivity, production scope, and blast radius to choose the path.\n\n5. Verify approvals\n\nConfirm required approvals and justification exist; missing approval means request-info or escalate, never grant.\n\n6. Provision or escalate\n\nAuto-provision only standard, low-risk, role-appropriate access (least-privilege, time-bound if possible); escalate privileged/sensitive/SoD cases.\n\n7. Audit\n\nLog every decision with the policy basis, approvals, and risk rationale for review and access certification.\n\n## Examples\n\nStandard role-based access, approved → auto-provision (least privilege)\n\nAn engineer requests read access to a dev tool their role normally has, with manager approval. Low risk, in-policy.\n\nInput\n\n```\nRequest REQ-5512: engineer requests read access to the staging dashboard. Role policy lists staging:read as standard for engineers. Manager approval present.\n```\n\nOutput\n\n```\n{\n  \"request_id\": \"REQ-5512\",\n  \"requester_role\": \"Engineer / Platform\",\n  \"requested_access\": \"staging-dashboard:read\",\n  \"risk\": \"low\",\n  \"policy_basis\": \"entitlement: 'staging:read' is standard for the Engineer role\",\n  \"sod_conflict\": \"none\",\n  \"approvals\": \"present (manager approved)\",\n  \"decision\": \"AUTO_PROVISION\",\n  \"grant\": { \"access\": \"staging-dashboard:read\", \"time_bound\": \"standing\", \"applied\": true },\n  \"actions\": [ { \"tool\": \"provision_access\", \"args\": { \"user\": \"REQ-5512.requester\", \"access\": \"staging-dashboard:read\" }, \"requires_approval\": false } ],\n  \"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.\",\n  \"escalation\": { \"needed\": false, \"to\": \"none\", \"reason\": \"\" }\n}\n```\n\n**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.\n\nProduction/admin access requested → never auto-grant, escalate\n\nA developer requests admin access to a production database. Regardless of approval, the high-risk rule forces escalation.\n\nInput\n\n```\nRequest REQ-5570: developer requests admin (write) access to the production payments database, justification 'need to debug an issue'.\n```\n\nOutput\n\n```\n{\n  \"request_id\": \"REQ-5570\",\n  \"requester_role\": \"Engineer / Payments\",\n  \"requested_access\": \"prod-payments-db:admin (write)\",\n  \"risk\": \"high\",\n  \"policy_basis\": \"prod:* and *:admin are privileged — not standard for the Engineer role\",\n  \"sod_conflict\": \"none\",\n  \"approvals\": \"manager approval present; resource-owner approval NOT present\",\n  \"decision\": \"ESCALATE\",\n  \"grant\": { \"access\": \"\", \"time_bound\": \"\", \"applied\": false },\n  \"actions\": [ { \"tool\": \"escalate_to_security\", \"args\": { \"to\": \"security+db_owner\", \"priority\": \"high\" }, \"requires_approval\": false } ],\n  \"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.\",\n  \"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.\" }\n}\n```\n\n**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.\n\nSeparation-of-duties conflict → block and escalate\n\nSomeone who can already create vendors requests payment-approval access. Granting it would create a fraud-enabling toxic combination.\n\nInput\n\n```\nRequest REQ-5604: a finance ops user with existing 'vendor:create' access requests 'payment:approve' access.\n```\n\nOutput\n\n```\n{\n  \"request_id\": \"REQ-5604\",\n  \"requester_role\": \"Finance Ops\",\n  \"requested_access\": \"payment:approve\",\n  \"risk\": \"high\",\n  \"policy_basis\": \"payment:approve is grantable to the role, BUT SoD policy forbids it combined with existing access\",\n  \"sod_conflict\": \"Requester already holds 'vendor:create'; combining with 'payment:approve' violates SoD (one person could create a vendor and approve its payments)\",\n  \"approvals\": \"manager approval present\",\n  \"decision\": \"ESCALATE\",\n  \"grant\": { \"access\": \"\", \"time_bound\": \"\", \"applied\": false },\n  \"actions\": [ { \"tool\": \"escalate_to_security\", \"args\": { \"to\": \"security+finance_controls\", \"conflict\": \"vendor:create + payment:approve\" }, \"requires_approval\": false } ],\n  \"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).\",\n  \"escalation\": { \"needed\": true, \"to\": \"security\", \"reason\": \"Separation-of-duties conflict: vendor:create + payment:approve on one identity enables fraud; needs controls review.\" }\n}\n```\n\n**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.\n\n## Implementation notes\n\n- Default to least privilege and time-bound/just-in-time grants; standing privileged access is the thing this agent exists to avoid handing out.\n- Enforce the 'never auto-grant privileged/production/sensitive' rule and the SoD check in a deterministic gate — these are security controls, not model preferences.\n- Run separation-of-duties against the requester's existing access, not just the new request; toxic combinations are invisible if you only look at one entitlement.\n- Verify approvals actually exist before provisioning; a missing resource-owner approval is an escalation, never an assumption.\n- Log every decision with policy basis, approvals, and risk for access certification and audit — this is also what makes the agent defensible to security review.\n- Have the agent suggest least-privilege alternatives (time-bound read, break-glass) when escalating high-risk requests, rather than just relaying them.\n- Spend the strong model on risk and SoD judgment — a cheaper model can resolve identity and look up policy.\n\n## Variations\n\nBasic\n\nRequest triage assistant\n\nValidates the request, checks policy and separation-of-duties, scores risk, and recommends grant/escalate for an IT analyst. No autonomous provisioning.\n\nAdvanced\n\nGuarded auto-provisioning\n\nAuto-provisions standard low-risk, role-appropriate access (least-privilege, time-bound) with approval verification, and escalates privileged/sensitive/SoD-conflict requests.\n\nEnterprise\n\nGoverned access automation\n\nAdds IGA/IAM integration, role-mining and entitlement catalogs, JIT access, full audit and access-certification support, and policy tuning — privileged access always human-approved.\n\nDownload the Agent Blueprint\n\n[Download Blueprint (.zip)](/downloads/access-request-handler.zip)\n\nExport\n\n[View the source on GitHub](https://github.com/agent-kits/agentaz/tree/main/kits/access-request-handler)\n\nThis flagship blueprint and the AgentAz™ specification live in the central AgentKits registry — open source under Apache-2.0 (code & schema) and CC‑BY‑4.0 (text).\n\n## Frequently asked questions\n\nNever. Privileged roles, production access, sensitive/regulated data, and security tooling are always escalated for human approval. It only auto-provisions standard, low-risk, role-appropriate access.\n\nIt grants the minimum access the role clearly warrants for the stated need — read instead of write where that suffices — and prefers time-bound/just-in-time grants over standing access, citing the policy basis each time.\n\nBefore granting, it compares the request against the requester's existing access to catch toxic combinations (like create-vendor + approve-payment, or develop + deploy-to-prod). Any conflict blocks auto-provisioning and is escalated.\n\nNo. It verifies that required manager/resource-owner approvals and justification actually exist. Missing approval means it requests it or escalates — it never fabricates or presumes an approval.\n\nYes. Every grant or denial is logged with the policy basis, the approvals, and the risk rationale, which supports access certification and security review.\n\nStart in advise mode where it recommends, backtest on past requests to confirm it never auto-grants privileged access or SoD conflicts, then enable auto-provisioning for standard low-risk requests.", "url": "https://wpnews.pro/news/access-request-provisioning-agent", "canonical_source": "https://www.agent-kits.com/kit/access-request-handler", "published_at": "2026-06-21 00:00:00+00:00", "updated_at": "2026-06-26 22:03:29.304614+00:00", "lang": "en", "topics": ["ai-safety", "ai-policy", "ai-agents", "ai-research", "developer-tools"], "entities": ["AgentKit", "AgentAz", "GitHub", "Apache-2.0"], "alternates": {"html": "https://wpnews.pro/news/access-request-provisioning-agent", "markdown": "https://wpnews.pro/news/access-request-provisioning-agent.md", "text": "https://wpnews.pro/news/access-request-provisioning-agent.txt", "jsonld": "https://wpnews.pro/news/access-request-provisioning-agent.jsonld"}}