CinvanaAI
← All projects

Library · Workflows & capabilities

Agent Workflow Governance

Give an agent permission for specific package actions and record blocked or completed runs.

Repository: CinvanaAI/agent-workflow-governance

Recorded synthetic example. Source with a complete offline example.

See the idea in action.

An inactive agent is refused; permission allows a run. Restart preserves configuration, and revocation blocks a later request.

Example input
A new document-reviewer agent and one synthetic file assignment.
Captured result
{
  "inactive": "blocked",
  "permitted": "complete",
  "revoked": "blocked",
  "permittedTargets": 1,
  "afterRestart": "blocked",
  "decisions": {
    "inactive": {
      "status": "blocked",
      "checks": [
        {
          "checkId": "agent-active",
          "ok": false,
          "summary": "Agent is inactive."
        },
        {
          "checkId": "workflow-enabled",
          "ok": true,
          "summary": "Workflow is enabled."
        },
        {
          "checkId": "workflow-tools-declared",
          "ok": true,
          "summary": "Workflow tools are declared on the agent definition."
        },
        {
          "checkId": "target-permissions",
          "ok": true,
          "summary": "All visible workflow targets satisfy keycard and per-tool file permissions."
        }
      ],
      "denials": [
        "Agent is inactive."
      ]
    },
    "permitted": {
      "status": "complete",
      "checks": [
        {
          "checkId": "agent-active",
          "ok": true,
          "summary": "Agent activation gate is open."
        },
        {
          "checkId": "workflow-enabled",
          "ok": true,
          "summary": "Workflow is enabled."
        },
        {
          "checkId": "workflow-tools-declared",
          "ok": true,
          "summary": "Workflow tools are declared on the agent definition."
        },
        {
          "checkId": "target-permissions",
          "ok": true,
          "summary": "All visible workflow targets satisfy keycard and per-tool file permissions."
        }
      ],
      "denials": []
    },
    "revoked": {
      "status": "blocked",
      "checks": [
        {
          "checkId": "agent-active",
          "ok": true,
          "summary": "Agent activation gate is open."
        },
        {
          "checkId": "workflow-enabled",
          "ok": true,
          "summary": "Workflow is enabled."
        },
        {
          "checkId": "workflow-tools-declared",
          "ok": true,
          "summary": "Workflow tools are declared on the agent definition."
        },
        {
          "checkId": "target-permissions",
          "ok": false,
          "summary": "1 workflow target(s) failed runtime file permission checks."
        }
      ],
      "denials": [
        "1 workflow target(s) failed runtime file permission checks."
      ]
    }
  },
  "targetPreview": {
    "workflowId": "workflow:demo.reviewer.1:manual",
    "instanceId": "demo.reviewer.1",
    "targets": [
      {
        "path": "/synthetic/brief.txt",
        "kind": "file",
        "permitted": true,
        "reason": "File is visible and all workflow tools have direct permission."
      }
    ],
    "warnings": []
  },
  "scope": "Permission decisions and target evidence only; no source file was read."
}

Try the example.

From the repository root, follow the dependency requirements in the README. This example uses supplied synthetic material.

npm ci
npm run demo

An inactive agent is refused; permission allows a run. Restart preserves configuration, and revocation blocks a later request.

Complete setup and instructions ↗

The interesting part.

Workflow permissions are inspectable records that can be checked before an execution handoff.

Focused extraction

Where it came from.

Agent runtime rules from the owner-governed Skeleton rebuild.

Preserves agent/storage/handoff/executor records and adds standalone synthetic examples and checks.

A selected subsystem snapshot, not a separate historical whole workbench.

Source ↗

Follow the family: Skeleton and the ownership rebuild

  • Extracted fromSkeleton

    See the integrated setting from which this independently useful mechanism was separated. The parent implementation remains present. The relationship is provenance, not a package-manager dependency.

    Source ↗