PUNK

// governance checklist

Reuse agent work without dropping your rules.

Proven work is useful only when the same customer, permissions, freshness, and approval rules still apply. This checklist explains the controls that safe reuse must preserve.

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 level Typical work Governance posture
0 Pure computation May qualify automatically after appropriate evidence and policy checks
1 Read-only external call Require freshness, authorization, and subject-aware scope
2 Reversible or idempotent write Require declared behavior, safeguards, and a rollback story
3 User-visible write such as an email, ticket, or message Use dry-run or shadow controls and often human approval
4 High-impact action such as payment, deletion, or permissions Default 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

Find repetition without weakening control.

Bring one real workload. Punk will show what repeats while keeping sensitive and uncertain work on its approved path.

Find what your agents can reuseSee a real example