---
title: "Agent Skills Governance"
canonical: "https://helm.docs.mindburn.org/teams"
source: "helm-ai-enterprise/docs/public/product/agent-skills-governance.md"
edit: "https://github.com/Mindburn-Labs/helm-ai-enterprise/edit/main/docs/public/product/agent-skills-governance.md"
section: "teams"
access: "public"
sensitivity: "public"
last_reviewed: "2026-05-04"
checksum_sha256: "sha256:6105e219781bf625fea989e41737159d5b2bc56195008975fad05286ea0b4a4d"
build_timestamp: "2026-05-24T13:40:27.882Z"
---
# Agent Skills Governance

HELM AI Enterprise turns the OSS execution boundary into a shared operating surface for groups that run AI agents, internal tools, and approval workflows together. The product goal is simple: every consequential action has an owner, a policy, a decision, and a receipt.

## Audience

Use this page if you administer a team workspace, design an approval flow, issue API keys, or evaluate whether autonomous work can be governed without forcing every developer to become a policy expert.

## Outcome

After reading this page you should be able to design a team rollout with:

- workspaces mapped to products, environments, or business units;
- API keys scoped to agents, services, and environments;
- role models for developers, approvers, auditors, and admins;
- policy bundles that define allowed, denied, and escalated actions;
- audit trails that connect every action to a receipt;
- team administration practices that preserve least privilege.

## Governance Lifecycle

```mermaid
flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Workspace["Create workspace"]
        Roles["Assign roles"]
        Keys["Issue scoped API keys"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        Bundle["Attach policy bundle"]
        Review["Review, export, and refine policy"]
    end

    subgraph Execution["3. Execution & Verdict Plane"]
        Runtime["Route agent/tool calls"]
        Decision{"Allow, deny, or escalate"}
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Receipt["Receipt and audit trail"]
    end

    %% Operational Flow Edges
    Workspace --> Roles
    Roles --> Keys
    Keys --> Bundle
    Bundle --> Runtime
    Runtime --> Decision
    Decision --> Receipt
    Receipt --> Review
    Review --> Bundle

    %% Premium Styling Rules
    style Bundle fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style Runtime fill:#3182ce,stroke:#2b6cb0,stroke-width:2px,color:#fff
    style Decision fill:#e53e3e,stroke:#9b2c2c,stroke-width:2px,color:#fff
    style Receipt fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
    style Review fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
```


## Source Truth

The public Individual route is backed by HELM product docs, the commercial `/api/basic` router, and the operator API surface:

- `commercial/basic/server.go`
- `commercial/basic/workspace.go`
- `commercial/basic/rbac.go`
- `commercial/basic/apikey.go`
- `commercial/basic/approval.go`
- `commercial/basic/evidence_index.go`
- `commercial/basic/runtime_bridge.go`
- `apps/helm-ai-enterprise/main.go`
- `docs/public/product/console-api.md`
- `docs/public/product/policy-bundles.md`
- `docs/public/product/policy-backends.md`
- `docs/public/security-and-trust/security-model.md`
- `docs/11_API_REFERENCE.md`

Use those references for exact endpoint names, payloads, and policy syntax.
Non-`/api/basic/*` commercial routes are not Individual API surface area. Billing,
trial, provisioning, admin, SCIM, and compliance endpoints are owned by the
commercial gateway and classified in `docs/11_API_REFERENCE.md`.

## Individual API Classification

The Individual API is mounted at `/api/basic/` by the commercial server. It is separate from the Console `/api/v1` route registry.

| Class | Routes | Use |
| --- | --- | --- |
| Workspace administration | `/api/basic/workspaces`, `/api/basic/projects`, `/api/basic/environments`, `/api/basic/members` | Create workspaces, project scopes, environments, and role assignments. |
| Keys and approvals | `/api/basic/keys`, `/api/basic/approvals` | Issue scoped API keys and request or inspect approval gates. |
| Evidence | `/api/basic/evidence` | Search evidence by workspace, project, run, decision, or principal. |
| Incidents and budgets | `/api/basic/incidents`, `/api/basic/incidents/transition`, `/api/basic/budget/record`, `/api/basic/budget/summary` | Track operational incidents and budget posture. |
| Plans and blast radius | `/api/basic/plans`, `/api/basic/plans/approve`, `/api/basic/plans/commit`, `/api/basic/blastradius` | Review, approve, commit, and estimate governed operational changes. |
| Notifications | `/api/basic/notifications/subscribe`, `/api/basic/notifications/emit` | Subscribe to or emit team notifications. |
| Runtime bridge | `/api/basic/runtime/start`, `/api/basic/runtime/stop`, `/api/basic/runtime/status` | Start, stop, or inspect workspace runtime state. |

## Workspace Model

A workspace is the administrative unit for a governed execution context. Most teams use one of three patterns:

| Pattern | Use When | Notes |
| --- | --- | --- |
| Product workspace | A product team owns agents and approvals end to end. | Good default for application teams. |
| Environment workspace | Staging and production need different policies. | Useful when production requires stricter escalation. |
| Business-unit workspace | Different units need separate auditors and retention. | Useful for regulated teams or internal platforms. |

Keep workspace boundaries aligned with who can approve an effect. Avoid a single shared workspace for unrelated applications.

## Roles

| Role | Typical Permissions | What They Should Not Do |
| --- | --- | --- |
| Developer | Create test agents, inspect denied receipts, request policy changes. | Approve their own production side effects. |
| Approver | Review escalations, approve bounded actions, add notes. | Modify policy bundles without review. |
| Auditor | Export receipts, verify evidence, inspect policy versions. | Execute tools or create new keys. |
| Admin | Manage workspaces, roles, keys, retention, and integrations. | Bypass policy evaluation. |

## API Keys

Keys should be scoped by workspace, environment, and agent class. A useful key name includes the owning service, environment, and purpose, for example `checkout-agent-prod-governed-tools`.

Minimum practice:

1. Create separate keys for local development, CI, staging, and production.
2. Rotate keys when a service owner changes.
3. Bind production keys to stricter policy bundles.
4. Store key issuance and rotation events in the audit trail.
5. Never use a human admin key inside an autonomous agent.

## Policy Bundles

Teams should treat policy bundles as versioned operational code. A bundle answers:

- which tools can be called;
- which argument shapes are allowed;
- which identities can act;
- which effects require approval;
- which egress destinations are blocked;
- what evidence must be retained.

Use the policy bundles reference for exact syntax. In a team rollout, start with a deny-by-default bundle, add one allowed workflow, then expand based on receipts rather than guesses.

## Approval Flows

Escalation should be reserved for actions where a human decision is meaningful:

- production deploys;
- outbound customer communication;
- financial or billing changes;
- data export;
- policy changes;
- destructive operations.

An approval event should record the requested action, policy version, approver identity, decision, timestamp, and receipt reference. Approval does not replace HELM evaluation; it becomes part of the evidence chain.

## Audit Trails

The audit trail is useful only if it can answer concrete questions:

- Who or what requested the action?
- Which workspace and policy bundle were active?
- What was allowed, denied, or escalated?
- Which receipt proves the decision?
- What changed after the decision?
- Can the receipt be exported and verified?

Teams should review denied and escalated receipts weekly during rollout. Denies reveal missing grants, unsafe tool shapes, and agents attempting actions beyond their intended scope.

## Redaction Boundary

Individual docs may show sample tenant, workspace, project, and environment IDs. They may describe key scopes and approval payload shapes. They must not show live API keys, raw customer evidence, session cookies, private tenant payloads, production webhook secrets, or unredacted SIEM export samples.

## Troubleshooting

| Symptom | Likely Cause | Fix |
| --- | --- | --- |
| Developers cannot reproduce production decisions | Dev and prod use different bundles without recorded versions | Pin bundle versions and show them in receipt metadata. |
| Too many escalations | Bundle is overly broad in effect classification | Split high-risk effects from routine allowed effects. |
| Receipts have unknown actors | Shared API key or missing agent identity | Issue per-agent keys and require identity claims. |
| Auditors cannot answer why a call was allowed | Missing policy version or source link | Require bundle hash and edit-source link in exports. |
| Policy changes are risky | No review workflow | Require a policy PR plus an approver before production attach. |

## Next Pages

- [Operator Console API](/product/console-api)
- [Policy Bundles](/product/policy-bundles)
- [Policy Backends](/product/policy-backends)
- [Security Model](/trust)