Profile Examples

Ready-to-use permission profiles and usage patterns for the Agent Vault Protocol.

How profiles work

AVP uses YAML permission profiles to control which credentials an agent can access. You can create as many profiles as you need — one per agent, one per environment, or one per trust level.

Each profile has a name, description, trust level (0–100), TTL (session duration in seconds), and an ordered list of rules. Rules use three pattern types — wildcard (*), prefix (AWS_*), or exact match (NODE_ENV) — and are evaluated using last-match-wins semantics.

Profiles are stored as .agentvault/profiles/*.yml files. You select which profile to apply when spawning an agent. Below are five ready-to-use profiles for common scenarios.

Restrictive Profile

Minimal access for untrusted or new agents. Trust level 10, 5-minute TTL.

This is the most restrictive profile. It denies access to all credentials, relying solely on system variable passthrough (PATH, HOME, etc.). Use this for agents you don't fully trust or as a starting point when onboarding a new tool.

restrictive.yml(YAML)

name: restrictive
description: Minimal access — denies everything except system vars. For untrusted or new agents.
trustLevel: 10
ttlSeconds: 300
rules:
  - pattern: "*"
    access: deny

Moderate Profile

Balanced access for known agents. Trust level 50, 1-hour TTL.

The most common profile for day-to-day development. Allows common development variables, redacts cloud credentials and API keys so the agent knows they exist but can't read the values.

moderate.yml(YAML)

name: moderate
description: Balanced — allows common dev vars, redacts secrets, denies cloud credentials.
trustLevel: 50
ttlSeconds: 3600
rules:
  - pattern: "*"
    access: deny
  - pattern: NODE_ENV
    access: allow
  - pattern: NPM_*
    access: allow
  - pattern: DEBUG
    access: allow
  - pattern: LOG_LEVEL
    access: allow
  - pattern: PORT
    access: allow
  - pattern: HOST
    access: allow
  - pattern: DATABASE_URL
    access: redact
  - pattern: AWS_*
    access: redact
  - pattern: OPENAI_*
    access: redact
  - pattern: ANTHROPIC_*
    access: redact

Last-Match-Wins:Rules are evaluated top-to-bottom. The first rule denies everything, then subsequent rules override for specific variables. AWS_SECRET_KEY matches both "*" (deny) and "AWS_*" (redact) — the last match (redact) wins.

Permissive Profile

Full access with audit trail. Trust level 90, 24-hour TTL.

For fully trusted agents that need access to all credentials. Everything is allowed, but every access is still logged to the audit trail. Useful during initial development or for agents that are extensively vetted.

permissive.yml(YAML)

name: permissive
description: Full access with audit trail — allows everything, logs all access. For trusted agents.
trustLevel: 90
ttlSeconds: 86400
rules:
  - pattern: "*"
    access: allow

Cloud Redact Profile

Allows dev vars, redacts all cloud provider credentials. Trust level 40.

Designed for multi-cloud environments. Redacts credentials for AWS, GCP, Azure, and AI API providers while allowing basic development variables. The agent can see that cloud credentials exist (useful for debugging) but cannot read their values.

cloud-redact.yml(YAML)

name: cloud-redact
description: Allows dev vars, redacts all cloud provider credentials.
trustLevel: 40
ttlSeconds: 1800
rules:
  - pattern: "*"
    access: deny
  - pattern: NODE_ENV
    access: allow
  - pattern: PORT
    access: allow
  - pattern: HOST
    access: allow
  - pattern: DEBUG
    access: allow
  - pattern: AWS_*
    access: redact
  - pattern: GCP_*
    access: redact
  - pattern: AZURE_*
    access: redact
  - pattern: OPENAI_*
    access: redact
  - pattern: ANTHROPIC_*
    access: redact
  - pattern: DATABASE_URL
    access: redact

CI Read-Only Profile

Allows CI pipeline variables, denies all secrets. Trust level 30.

For agents running in continuous integration environments. Allows CI-specific variables (CI, CI_*, GITHUB_*) and common build variables, but denies access to all secrets. Short 10-minute TTL.

ci-readonly.yml(YAML)

name: ci-readonly
description: Read-only CI environment — allows CI vars, denies all secrets.
trustLevel: 30
ttlSeconds: 600
rules:
  - pattern: "*"
    access: deny
  - pattern: CI
    access: allow
  - pattern: CI_*
    access: allow
  - pattern: GITHUB_*
    access: allow
  - pattern: NODE_ENV
    access: allow
  - pattern: NPM_*
    access: allow

Audit Log Example

What audit trail entries look like in practice.

When an agent runs with the moderate profile and the environment contains AWS_SECRET_KEY, NODE_ENV, and DATABASE_URL, the audit trail records each decision:

Audit Trail Output(JSON)

[
  {
    "id": 1,
    "sessionId": "550e8400-e29b-41d4-a716-446655440000",
    "agentId": "claude-code",
    "profileName": "moderate",
    "varName": "NODE_ENV",
    "action": "allow",
    "timestamp": "2026-03-09T14:00:01Z"
  },
  {
    "id": 2,
    "sessionId": "550e8400-e29b-41d4-a716-446655440000",
    "agentId": "claude-code",
    "profileName": "moderate",
    "varName": "AWS_SECRET_KEY",
    "action": "redact",
    "timestamp": "2026-03-09T14:00:01Z"
  },
  {
    "id": 3,
    "sessionId": "550e8400-e29b-41d4-a716-446655440000",
    "agentId": "claude-code",
    "profileName": "moderate",
    "varName": "DATABASE_URL",
    "action": "redact",
    "timestamp": "2026-03-09T14:00:01Z"
  }
]

Memory Entry Example

How agent memory entries are structured.

Knowledge Memory Entry(JSON)

{
  "key": "api-rate-limits-openai",
  "vaultType": "memory",
  "memoryType": "knowledge",
  "tags": ["api", "openai", "rate-limits"],
  "queryHash": "a3f2b8c1d4e5f6...",
  "keywords": ["openai", "rate", "limits", "tokens", "gpt-4"],
  "content": "OpenAI GPT-4 rate limits: 10,000 tokens/min for tier 1, 60,000 for tier 2. Rate limit headers: x-ratelimit-remaining-tokens.",
  "confidence": 0.95,
  "source": "openai-docs",
  "expiresAt": "2026-06-01T00:00:00Z",
  "accessCount": 3,
  "addedAt": "2026-03-09T14:00:00Z"
}

Query Cache Entry(JSON)

{
  "key": "cache-npm-audit-results",
  "vaultType": "memory",
  "memoryType": "query_cache",
  "tags": ["npm", "security", "audit"],
  "queryHash": "b4c3d2e1f0...",
  "keywords": ["npm", "audit", "vulnerabilities", "security"],
  "content": "npm audit found 0 vulnerabilities in 847 packages. Last run: 2026-03-09.",
  "confidence": 1.0,
  "source": "npm-audit",
  "expiresAt": "2026-03-10T14:00:00Z",
  "accessCount": 0,
  "addedAt": "2026-03-09T14:00:00Z"
}

Session Lifecycle

How sessions are created, tracked, and revoked.

Active Session(JSON)

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "agentId": "claude-code",
  "profileName": "moderate",
  "pid": 12345,
  "startedAt": "2026-03-09T14:00:00Z",
  "active": true
}

The agent's environment receives three metadata variables:

Injected Environment

AGENTVAULT_SESSION=550e8400-e29b-41d4-a716-446655440000
AGENTVAULT_PROFILE=moderate
AGENTVAULT_TRUST=50

When the session is revoked (via kill switch or TTL expiry), the agent process receives SIGTERM and the session is marked as inactive.