PUNK

// governance checklist

Enterprise agent governance belongs in the execution path.

A policy document cannot explain a route after the fact or stop a model-driven action before it happens. Practical governance connects identity, tools, data, approvals, and evidence to the actual request path.

Product-fit boundary

Punk can apply policy to supported model requests and declared, instrumented tool actions. It supports evidence-aware routing and selected approval flows, but it is not a compliance certification or a substitute for your organization’s legal, security, and access-control program.

// control checklist

Make the following decisions explicit.

Identity and scope

  • Who owns the tenant, application, agent, and subject for each run?
  • Which credentials and permission scopes apply to each tool?
  • Which dimensions must remain in cache keys and reusable-route matching?
  • How are environment and policy versions recorded?

Tool and action policy

  • Which tools are declared, and what side-effect level does each operation carry?
  • What happens to unknown tools or incomplete declarations?
  • Which reads need freshness, subject scope, or a TTL?
  • Which writes must block, dry-run, use idempotency, or wait for approval?

Evidence and change control

  • Which routes can use cache, plan reuse, artifacts, or another model?
  • What replay, shadow, and quality thresholds qualify each task class?
  • Who can promote, pin, quarantine, or roll back a route?
  • How is schema drift or negative feedback handled?

Data and auditability

  • What trace fields are retained, redacted, exported, or deleted?
  • Are raw traces tenant-isolated and excluded from cross-tenant learning by default?
  • Can an investigator inspect policy, route, tools, and approval state by run?
  • Which deployment controls need separate validation?

// make risk operational

Different actions deserve different gates.

Risk levelTypical workGovernance posture
0Pure computationMay qualify automatically after appropriate evidence and policy checks
1Read-only external callRequire freshness, authorization, and subject-aware scope
2Reversible or idempotent writeRequire declared behavior, safeguards, and a rollback story
3User-visible write such as an email, ticket, or messageUse dry-run or shadow controls and often human approval
4High-impact action such as payment, deletion, or permissionsDefault to conservative live and human-approved paths

Policy outranks optimization. A route that saves tokens but conflicts with identity, approval, or action policy should remain blocked or live according to your controls.

// review sequence

Begin with a governed pilot, not an organization-wide switch.

  1. Map one workflow’s real boundary

    Inventory inputs, models, tools, data classes, subjects, side effects, owners, and existing approvals. Include what the integration cannot currently see.

  2. Observe before enforcing

    Use compatible traffic to validate trace completeness and model the decisions policy will need to make. Do not infer enforcement coverage from a dashboard alone.

  3. Set conservative defaults

    Keep unknown or consequential tool behavior conservative; define approval, idempotency, fallback, and rollback expectations before enabling a reusable path.

  4. Test evidence and audit retrieval

    Review a normal run, a policy block, a suppressed side effect, and an optimization fallback with the people responsible for operations and risk.

Review security boundariesOpen policy examples

Bring policy to the route that actually runs.

Start with an observe-only workload or request a review for a security-sensitive pilot with your real tool, data, and approval constraints.

Start freeRequest a workload review