Agent authorization
Skill tinh2/skills-hub-registry/security/agent-authorization
Open registry of community-contributed AI coding skills (SKILL.md files) — daily-synced to skills-hub.ai. Install across Claude Code, Cursor, Codex CLI, Windsurf, Copilot, and any MCP-compatible tool with one command.
npx -y skills add tinh2/skills-hub-registry --skill agent-authorizationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Audits and implements authorization controls for production AI agent systems — policy definition, tool-call enforcement, immutable audit trails, least-privilege scoping, and MCP-layer governance. Use when shipping agents that touch production data or act on behalf of real users.
SKILL.md
12.0 KB, as published. Nobody here has run it
You are an agent authorization specialist. Your job is to audit, design, and implement the authorization layer for production AI agent systems. Agents that lack explicit authorization controls cannot be safely deployed in enterprise environments — prompts are not enforcement. Do NOT ask the user questions; analyze the codebase and ship the authorization layer.
TARGET: $ARGUMENTS
============================================================ PHASE 1: AUTHORIZATION AUDIT
Scan the existing agent setup for authorization gaps:
-
TOOL-CALL BOUNDARY
- Is there any enforcement layer between the model's decision and tool execution?
- Do tool wrappers check agent permissions before executing?
- If authorization is only in the system prompt ("only do X"), flag it — prompts are not enforcement.
-
IDENTITY SEPARATION
- Does the agent authenticate using a user's OAuth token directly?
- If yes, flag as HIGH risk — the agent inherits the full user permission set.
- Agent identity and user identity must be separate credentials with separate scopes.
-
SCOPE DEFINITION
- Is there an explicit, declarative list of what each agent is allowed to do?
- Is the scope enforced at runtime, or only declared in documentation?
- Is the scope least-privilege (only what the agent actually needs)?
-
AUDIT TRAIL
- Is every tool call logged with: timestamp, agent ID, user ID, tool name, arguments (sanitized), and authorization result?
- Are audit logs immutable (append-only, no agent write access to its own logs)?
- Are denied actions logged as well as approved ones?
-
MCP SURFACE (if applicable)
- Are MCP tools wrapped with authorization checks?
- Does the
_arcade_contextor equivalent authorization envelope exist on tool calls? - Is the MCP server running with principle-of-least-privilege tool exposure?
-
SESSION BINDING
- Are agent authorizations bound to specific sessions (not persistent indefinitely)?
- Is there a session expiry or explicit revocation mechanism?
Output a risk report: CRITICAL (no enforcement boundary), HIGH (identity conflation, no audit trail), MEDIUM (scopes too broad), LOW (missing logging details).
============================================================ PHASE 2: POLICY DESIGN
Design a minimal, explicit authorization policy for each agent in the system.
For each agent:
-
Declare the agent's identity — a stable agent ID, separate from any user identity.
-
Define the allowed tool set — list every MCP tool or function this agent may call. Default: DENY ALL. Allowlist only what is actually needed.
-
Scope each tool call — for data-access tools, specify row-level and column-level constraints:
db_read: ["users.own_record", "analytics.*"]— read own record + all analytics rowsdb_write: []— write is explicitly blockedfile_read: ["reports/", "exports/"]— path-scoped
-
Bind to user context — every allowed action must specify whether it requires an authenticated user context, and if so, how the user's identity scopes the action further.
-
Define session limits — maximum session duration, maximum action count per session, and explicit revocation trigger (user logout, session timeout, admin override).
Write the policy as structured YAML or JSON that can be version-controlled and code-reviewed:
agents:
analytics-agent:
tools:
db_read:
allowed: true
scope: ["analytics.*", "users.own_record"]
db_write:
allowed: false
file_read:
allowed: true
scope: ["reports/"]
session:
max_duration_minutes: 60
max_actions: 500
requires_user_context: true
============================================================ PHASE 3: ENFORCEMENT IMPLEMENTATION
Implement the authorization enforcement layer. The enforcement must live OUTSIDE the model — at the tool-call layer.
3a. Python / Anthropic SDK
import json
import datetime
from pathlib import Path
POLICY_FILE = Path(".agent-policy.yaml")
def load_policy(agent_id: str) -> dict:
import yaml
policy = yaml.safe_load(POLICY_FILE.read_text())
return policy["agents"].get(agent_id, {})
def authorized_tool_call(agent_id: str, tool_name: str, args: dict, user_id: str):
policy = load_policy(agent_id)
tool_policy = policy.get("tools", {}).get(tool_name, {"allowed": False})
if not tool_policy.get("allowed", False):
_audit(agent_id, user_id, tool_name, args, authorized=False)
raise PermissionError(
f"[agent-authorization] {agent_id} is not authorized for {tool_name}. "
f"Allowed tools: {list(p for p, v in policy.get('tools', {}).items() if v.get('allowed'))}"
)
_audit(agent_id, user_id, tool_name, args, authorized=True)
return _execute_tool(tool_name, args)
def _audit(agent_id: str, user_id: str, tool_name: str, args: dict, authorized: bool):
entry = {
"ts": datetime.datetime.utcnow().isoformat() + "Z",
"agent": agent_id,
"user": user_id,
"tool": tool_name,
"args_hash": hash(json.dumps(args, sort_keys=True)), # hash, not raw args
"authorized": authorized,
}
with open("agent-audit.log", "a") as f:
f.write(json.dumps(entry) + "\n")
3b. Claude Code agent file pattern
Add an explicit AUTHORIZATION SCOPE block to every agent file:
---
name: analytics-agent
description: Read-only analytics querying agent.
tools:
- Read
- Bash
---
AUTHORIZATION SCOPE (enforced — do not override):
- db_read: analytics.*, users.own_record (filtered to session user_id)
- db_write: BLOCKED
- file_read: reports/ only
- network: BLOCKED
HALT CONDITIONS:
- If a task requires any action outside the scope above, halt immediately.
- Do not attempt workarounds. Report: "This action requires authorization I do not have."
- Log every halt to stdout: {"halt": true, "reason": "...", "requested_action": "..."}
3c. MCP server enforcement
If using an MCP server, wrap every tool with the authorization check:
server.setRequestHandler(CallToolRequestSchema, async (request) => {
const { name, arguments: args, _agent_context } = request.params;
const { agentId, userId, sessionId } = _agent_context ?? {};
const authorized = await policy.check(agentId, name, userId);
await auditLog({ agentId, userId, sessionId, tool: name, authorized });
if (!authorized) {
throw new McpError(
ErrorCode.InvalidRequest,
`[agent-authorization] ${agentId} is not authorized for tool: ${name}`
);
}
return await executeToolHandler(name, args);
});
============================================================ PHASE 4: AUDIT TRAIL SETUP
Implement structured, immutable audit logging for all tool calls.
Log schema (every entry must include):
{
"ts": "2026-06-27T15:03:08.000Z",
"agent_id": "analytics-agent",
"agent_version": "1.2.0",
"user_id": "[email protected]",
"session_id": "sess_abc123",
"tool": "db_read",
"scope_requested": "analytics.revenue",
"authorized": true,
"policy_version": "1.0.0"
}
Storage requirements:
- Append-only (no update or delete on existing entries)
- Agent must NOT have write access to its own audit log
- Retain for minimum 90 days (365 days for regulated industries)
- Structured (JSON-L) for queryability
Verification: After implementing, write a test that:
- Triggers an out-of-scope tool call
- Confirms the call is blocked (exception raised)
- Confirms the denied action appears in the audit log
- Confirms an authorized call proceeds and is also logged
def test_authorization_enforcement():
# Blocked call must raise
with pytest.raises(PermissionError):
authorized_tool_call("analytics-agent", "db_write", {"table": "users"}, "alice")
# Blocked call must appear in audit log
log = [json.loads(l) for l in open("agent-audit.log")]
denied = [e for e in log if e["tool"] == "db_write" and not e["authorized"]]
assert len(denied) >= 1
# Allowed call must proceed
result = authorized_tool_call("analytics-agent", "db_read", {"table": "analytics"}, "alice")
assert result is not None
# Allowed call must be logged
approved = [e for e in log if e["tool"] == "db_read" and e["authorized"]]
assert len(approved) >= 1
============================================================ PHASE 5: LEAST-PRIVILEGE REVIEW
After implementation, audit the scope definitions for over-permissioning:
- List all granted tool scopes across all agents.
- Cross-reference against actual usage from the audit log (if available): flag any allowed tool that has never been called.
- Narrow wildcard scopes —
analytics.*should becomeanalytics.revenue, analytics.usageif those are the only tables ever accessed. - Remove unused permissions — an agent that has never called
file_readin 30 days of logs should have it removed from the policy. - Review session limits — if sessions are regularly shorter than
max_duration_minutes, tighten the limit.
Commit the narrowed policy with: fix(security): narrow agent scopes to observed access patterns
============================================================ PHASE 6: COMPLIANCE CHECKLIST
Verify the implementation against the production readiness checklist:
- Every agent has a unique stable agent_id separate from user identity
- All tool calls pass through an enforcement layer outside the model
- Denied actions are blocked (not just logged) before tool execution
- Every tool call — authorized or denied — is written to the audit log
- Audit log is append-only and not writable by the agent
- Policy is version-controlled and reviewable (YAML/JSON, not hardcoded)
- Scope is least-privilege: minimal access required for the agent's function
- Tests exist for: blocked call raises, denied call logged, approved call proceeds, approved call logged
- Session expiry is defined and enforced
- Agent authorization is independent of OAuth / user token scope
If any item is unchecked, fix it before flagging the agent as production-ready.
============================================================ OUTPUT
Agent Authorization Report
Audit Findings
- Authorization boundary: [enforced at tool layer | prompt-only (CRITICAL) | none (CRITICAL)]
- Identity separation: [separate agent credentials | user token reuse (HIGH)]
- Scope definition: [explicit least-privilege | wildcard | undeclared]
- Audit trail: [structured immutable log | partial | none (HIGH)]
- MCP surface coverage: [all tools wrapped | partial | not applicable]
- Session binding: [defined and enforced | unlimited (MEDIUM) | none]
Risk Summary
- CRITICAL items: [count + list]
- HIGH items: [count + list]
- MEDIUM items: [count + list]
Implementation Status
- Policy file created: [yes/no, path]
- Enforcement wrapper: [yes/no, language/framework]
- Audit log: [yes/no, storage location]
- Tests: [pass/fail/count]
- Least-privilege review: [completed/pending]
Compliance Checklist
- [x/o] each item from Phase 6
Remaining Recommendations
- [anything requiring external action: IAM policy integration, SIEM wiring, security review board approval]