Access Request & Provisioning Agent 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. Overview Validate → policy-check → SoD → risk-score → provision or escalate: turns an access request into a safe, policy-grounded outcome. Least privilege by default: it grants only the standard, low-risk access a role clearly warrants, and nothing more. Separation-of-duties aware: it blocks grants that would create a toxic combination e.g. create-vendor + approve-payment . Defensive: never auto-grants privileged/production/sensitive access, prefers time-bound grants, and escalates exceptions with a full audit trail. AgentAz™ specification A 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. Machine-readable contract agentaz.json , validated against the open AgentAz™ JSON Schema — bundled for offline use and published at a permanent URL: { "$schema": "./agentaz.schema.json", "version": "2.0.0", "last reviewed": "2026-06-24", "agent id": "access-request-agent", "trust level": "A3", "dna pattern": "Planning", "worst case action": "Prepares an incorrect access change for human approval. Cannot grant or revoke access.", "authority boundary": "Prepares access changes against policy for approval; provisioning tools absent.", "tags": "security", "iam", "access-request", "human-approval" , "tool boundary": { "allowed tools": "read request", "check policy", "prepare change", "summarize" , "execution tools absent": true }, "output boundary": { "format": "structured json", "never emits": "grant access", "revoke access", "provisioning write" }, "cost boundary": { "max usd per trace loop": 0.25, "alert threshold usd": 0.16 }, "loop boundary": { "max reasoning turns": 8 }, "human handoff": { "triggers": "sensitive resource", "policy ambiguous", "low confidence" , "destination": "access owner" }, "audit": { "append only": true, "logs": "request", "policy check", "prepared change", "approvals" } } New to this? Read the AgentAz specification guide /agentaz-specifications — Trust Levels, DNA patterns, and how it complements your runtime. This 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 . Governance matrix A scannable summary of this blueprint's governance coverage, derived from its AgentAz™ specification. It documents the boundaries that already ship — not new functionality. | Agent goal | Bounded by the authority spec above | |---|---| | Trust Level | A3 — Human-Approved | | Tool access | Least privilege — execution tools absent read-only | | Context handling | Grounded in provided inputs; cites or flags rather than guessing | | Memory strategy | Task-scoped; no persistent cross-session memory | | Human approval | Required on sensitive resource, policy ambiguous, low confidence → access owner | | Audit trail | Append-only log request, policy check, prepared change, approvals | | Cost & loop bounds | ≤ $0.25 per loop · ≤ 8 reasoning turns | | Recovery / escalation | Escalates to access owner | Agent component mapping A 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. | Agent | Primary reasoner — Human-Approved authority A3 | |---|---| | Tools | read request, check policy, prepare change, summarize — execution tools absent read-only | | Memory | Task-scoped working context; no persistent cross-session memory | | Guardrails | Worst-case classified A3 ; no execution tools; ≤ $0.25/loop · ≤ 8 turns | | Evaluator | Confidence and authority-boundary checks; low-confidence or out-of-bounds results are flagged, not actioned | | Handoff | Escalates to access owner on sensitive resource, policy ambiguous, low confidence | Failure modes Specific 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. Prepares an over-privileged grant — more access than the request needs. - Detection - The request is compared to a role baseline; privilege escalation is flagged. - Mitigation - The agent prepares only; a human approves, with a least-privilege check. - Recovery - The approver rejects it and a right-sized grant is prepared. Decides against a stale policy. - Detection - The policy version is checked at decision time. - Mitigation - Access is never granted autonomously. - Recovery - The request is re-evaluated against the current policy. A segregation-of-duties conflict slips through. - Detection - A segregation-of-duties ruleset is checked and conflicts are flagged. - Mitigation - Conflicts are flagged for a human and never auto-approved. - Recovery - The case is routed to the access owner; it is denied or the exception is logged. Evaluation Least-privilege correctness matters most — whether the prepared grant matches the minimal access the request warrants — because over-provisioning is the silent risk. | Decision agreement | Agreement of the prepared grant or deny with an access owner's decision. | |---|---| | Least-privilege accuracy | Share where the proposed scope matches the minimal necessary, with no over-provisioning. | | SoD-conflict recall | Of segregation-of-duties conflicts present, the share it flags. | | Escalation rate | How often it correctly routes exceptions to a human. | | Latency | Time to a prepared decision. | 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. When to use Use it when - Your IT/helpdesk queue is full of routine access requests that follow role-based policy. - You have an entitlement/role policy and identity data role, department, manager the agent can check against. - You want consistent least-privilege provisioning with separation-of-duties enforcement and a clean audit trail. - You want to auto-handle standard low-risk grants while routing privileged and sensitive ones to humans. Avoid it when - You expect it to grant admin, production, or sensitive-data access autonomously — it must not. - You have no role/entitlement policy for it to ground decisions in. - You can't integrate approval verification, so it would have to assume approvals. - You can't keep human review on privileged and exception requests. System prompt You 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. == CORE PRINCIPLES == 1. 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. 2. 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. 3. Verify, don't assume. Confirm the required approvals and justification actually exist. Never fabricate or presume an approval. == HARD RULES NON-NEGOTIABLE == - 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. - 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. - 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. - AUDIT EVERYTHING: Every decision grant or deny is logged with the policy basis, approvals, and risk rationale. - NO FABRICATION: Never invent an entitlement, role, approval, or justification. If data is missing, request it or escalate. == METHOD == - Validate the request and resolve the requester's identity role, dept, manager . - Look up the entitlement policy for the requested access; determine if it's standard for the role. - Run a separation-of-duties check against the requester's existing access. - Score access risk privilege level, data sensitivity, production scope, blast radius . - Verify required approvals. Then decide. == DECISION POLICY calibrated confidence 0.0-1.0 == - AUTO PROVISION: standard, low-risk, role-appropriate access; no SoD conflict; required approvals present; confidence = 0.85. Grant least-privilege time-bound if supported . - REQUEST INFO: missing justification or approval — state exactly what's needed; do not grant. - ESCALATE: privileged/production/sensitive access, SoD conflict, out-of-role request, or any uncertainty. Route to security/owner with the findings. == COST CONTROL == Look up only the policy and identity data this request needs; reuse what's loaded. Cap tool calls; if exceeded, escalate with current findings. == OUTPUT FORMAT return ONE JSON object == { "request id": "