Skip to content

Latest commit

 

History

History
84 lines (60 loc) · 3.51 KB

File metadata and controls

84 lines (60 loc) · 3.51 KB

Agent Access Policy Boundary Model

Purpose

This document closes public issue #3: Create an agent access policy example that separates identity, action scope, and audit evidence.

It provides concrete agentic-enterprise evidence for AccessGovernance Kit. The repo remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Agent-assisted access decisions, role assignment, policy evaluation, entitlement review, or delegated action execution.

Actors

Actor Responsibility
Requester Asks for access or delegates a task.
Approver Reviews policy, business reason, and risk before granting access.
Policy engine Evaluates identity, role, action, resource, and conditions.
Agent Prepares recommendations or action proposals but does not own approval authority.
Auditor Reviews evidence after access changes or denied requests.

Identity Boundary

  • Every action proposal must include subject, actor, tenant, resource, requested action, and reason.
  • The agent may recommend but cannot grant privileged access without a human or policy-approved control.
  • Service credentials and policy bindings are referenced by id, not embedded in prompts or docs.

Tool And Action Boundary

Action Boundary
policy.evaluate Allowed for proposed action and current identity context.
access.request Allowed with subject, resource, reason, duration, and risk class.
access.grant Requires policy decision and approval evidence for privileged scopes.
access.revoke Requires authority, target, and audit reason.
policy.change Requires maintainer or security-owner review.

Human Approval Gates

  • Before granting admin, production, billing, data-export, or cross-tenant access.
  • Before changing RBAC defaults or policy templates.
  • Before allowing an agent to execute side-effecting identity operations.
  • Before closing an access review with unresolved evidence gaps.

Audit Event Model

Event Minimum Evidence
policy.evaluation_requested subject, actor, action, resource, tenant, reason
policy.decision_recorded decision, matched rule, risk class, conditions
approval.required approver group, policy id, expiration
access.change_applied grant/revoke, actor, subject, resource, duration
access.review_completed reviewer, findings, exceptions, remediation

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint for static validation.
  • npm run test for policy examples when present.
  • npm run build to prove the app compiles.
  • Static inspection of policy examples, audit event definitions, and approval requirements.

OSS And Self-Hosted Fallbacks

  • Use Open Policy Agent or Cedar-style policy modeling for self-hosted policy evaluation.
  • Use PostgreSQL for role, entitlement, and access-review evidence.
  • Keep hosted auth providers behind adapters and document Auth.js/self-hosted alternatives.
  • Use OpenTelemetry or structured application logs for audit/event export.

Contributor Follow-Up

Add a sample policy JSON that carries subject, action, resource, decision, approval state, and audit event reference.

Issue Closure Evidence

This document satisfies the issue checklist by separating:

  • identity or actor boundary
  • tool/provider/action boundary
  • human approval or escalation point
  • audit or observability events
  • OSS/self-hosted fallback direction
  • validation and static inspection path