Skip to content

Introduce GitHub self‑governance (TTP governing TTP): docs, policies, workflows, agents, and TA updates - #16

Merged
blocksifrdev merged 4 commits into
mainfrom
codex/revise-ttp-integration-plan-for-agt-u2wzza
Apr 18, 2026
Merged

blocksifrdev merged 4 commits into
mainfrom
codex/revise-ttp-integration-plan-for-agt-u2wzza

Conversation

@blocksifrdev

Copy link
Copy Markdown
Collaborator

Motivation

  • Establish a reference architecture and operational guardrails for using TTP to govern GitHub actions (runtime authority gate, execution receipts, protected actions, and agent role manifests).
  • Harden the repo for an eventual public release by adding CODEOWNERS, repo access guidance, release/readiness checklists, and CI scaffolding.
  • Extend the reference Trust Authority implementation with admin/agent introspection, small crypto fixes, and unit coverage for the aggregation algorithm to increase confidence in issuance behavior.

Description

  • Add GitHub self‑governance materials including docs/github-self-governance-reference-architecture.md, docs/github-self-governance.md, runtime/api/re-authorize.contract.md, RFC rfcs/0001-github-self-governance-role-agents.md, and supporting docs (docs/*, spec/extensions/*, docs/open-source-boundary.md, docs/public-readiness.md, docs/repo-access-control.md, docs/getting-started.md, docs/operator-guide.md, etc.).
  • Add policy and protection artifacts: policy/*.yaml, policy/protected-actions.yaml, policy/trust-thresholds.yaml, and receipts/schemas/execution-receipt.v1.json plus spec/extensions/execution-receipt-v2.schema.json to define execution receipts and protected paths.
  • Add role/agent manifests and per-agent manifests under agents/ to describe workload identities and allowed actions for AI role‑agents (e.g. agents/manifests/role-agents.yaml, agents/*/manifest.json).
  • Add GitHub automation skeletons and gates: /.github/CODEOWNERS, /.github/workflows/ci.yml, /.github/workflows/ttp-protected-gate.yml, and /.github/workflows/ttp-governed-pr-action.yml to show how to call a Runtime Authority (POST /re/authorize) and enforce decisions in workflows.
  • Add an Authority service prototype and helpers in services/authority/ including a simple POST /re/authorize implementation, receipt signing/chain hashing, policy loader, and schemas to exercise the reference model.
  • Extend the reference Trust Authority reference implementation with: test config (jest.config.cjs), an aggregation unit test (src/aggregation.test.ts), package updates (package.json), TS config tweaks, store/router changes exposing GET /v1/admin/agents and metrics, helpers getAgentReceiptsAcrossDomains, and small fixes to @noble/ed25519 SHA-512 usage in crypto.ts, index.ts, and keygen script.
  • Update top-level documentation and README/CONTRIBUTING/SECURITY to reflect the governance model, docs split, and repo access controls.

Testing

  • Added unit tests for aggregation in reference-implementations/trust-authority/src/aggregation.test.ts and executed npm test in the reference-implementations/trust-authority package which passed locally.
  • Added a CI job CI -> trust-authority (.github/workflows/ci.yml) configured to run npm install, npm run build, and npm test for the trust authority; the workflow template is included to run these checks on push and pull_request events.
  • Manual smoke validation of the authority prototype services/authority exercised POST /re/authorize flows and receipt generation during development (prototype behavior exercised successfully).

Codex Task

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0ce58d9962

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

}

if (req.method === "POST" && url.pathname === "/re/authorize") {
const body = await parseBody(req) as AuthorizeRequest

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Catch JSON parse errors in /re/authorize handler

parseBody rejects on invalid JSON, but the /re/authorize route awaits it without a try/catch, so a malformed request triggers an unhandled exception in the async HTTP handler and can terminate the process instead of returning a 4xx error. Any client sending invalid JSON can take down this authority service instance.

Useful? React with 👍 / 👎.

}

function decide(req: AuthorizeRequest, protectedPaths: string[]): { decision: Decision; reason: string; context: DecisionContext } {
const protectedAction = req.pathsTouched.some(p => isProtectedPath(p, protectedPaths))

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Validate pathsTouched before calling .some

The request body is cast to AuthorizeRequest with no runtime validation, so if pathsTouched is missing or not an array, this .some(...) call throws a TypeError; in the current async server callback that exception is uncaught and can crash the service. Invalid/malformed caller payloads should be handled as a normal deny/400 path instead of process-fatal errors.

Useful? React with 👍 / 👎.

Comment on lines +65 to +67
if [ "$DECISION" != "PERMIT" ]; then
echo "Fail-closed: decision=$DECISION receipt=$RECEIPT"
exit 1

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep gate job successful for STEP_UP/ESCALATE outcomes

Failing protected-action-gate for every non-PERMIT decision prevents the downstream step-up-approval job from running because it depends on this job via needs, so manual approval/escalation paths are effectively unreachable. This makes STEP_UP/ESCALATE behave like hard-deny instead of entering the intended approval flow.

Useful? React with 👍 / 👎.

@blocksifrdev

Copy link
Copy Markdown
Collaborator Author

@copilot resolve the merge conflicts in this pull request

@blocksifrdev
blocksifrdev merged commit 0a477de into main Apr 18, 2026
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant