Keys and infrastructure

Section 17 of 22

Prefer agent-held keys for routine repository, deployment, and payment work. A TEE provides a protected environment in which the approved agent can hold and use a key. Recovery must check both the permitted code and the agent's current authorization. Previously approved code cannot regain a revoked permission merely by restarting.

Keep release authority and payment authority distinct. Safes or other bounded execution mechanisms may implement that separation. Exact owner counts, thresholds, and modules belong in the detailed design. Several keys under one person's upgrade and recovery control do not provide independent authority, even when they run on separate machines.

Reuse the existing registries and suitable governance components from the prior project where they enforce the chosen rules. Reuse does not require carrying over person-verification, token, or voting features that v2 has not selected. Move contract authority to the intended controllers before outside credentials or paid commitments depend on those permissions.

An executor can be replaced without giving its successor unrestricted power. Document who can admit new code, recover keys, change hosting permissions, and restore service after a failure. Test those paths before relying on unattended operation. Human hardware keys can support an initial or emergency arrangement with their powers stated openly.

Investigate agent-provisioned Git access using existing hosting and attestation infrastructure first. On-chain permission decisions can drive a job that grants or revokes repository access. A paid or self-hosted Git service remains an implementation option. A custom service or alternative-chain key store needs a demonstrated requirement that the simpler setup cannot meet.

Keep a small investigation into cloud cost access and shutdown controls. Local job budgets and resource limits provide immediate spending controls. Delayed provider cost records can reconcile actual charges. Preserve enough funded capacity for incident handling and recovery when discretionary jobs reach their limits.

Custody and replacement

A TEE protects the execution and secrets of admitted code under its platform's guarantees. It does not decide which role that code currently holds. Admission must check the expected code identity and the current role authorization before releasing credentials or accepting its signed actions.

Separate repository credentials, deployment access, release transaction authority, payment access, and recovery permission. Record who can upgrade the workers or recover their keys. Multiple enclaves under one unrestricted recovery key still share that authority.

The detailed custody implementation must specify controller contracts or wallets, signer thresholds where used, allowed call targets, limits, key renewal, revocation, and recovery. Do not inherit the old two-human-signature arrangement as a prerequisite. Evaluate suitable existing registries and governance components against these requirements before adding custom custody.

Recovery flow

F10 can start at any execution step. The flow records the original job so recovery resumes the correct action and preserves completed effects.

Step	Work and authority	Required outcome or failure
H01. Detect and scope	Controller records the failed capability, original step, last confirmed effect, and affected services.	Separate unavailable evidence from an actual failed behavior test. Apply scoped containment if required.
H02. Reconcile	Executor or operations worker checks whether the external action already succeeded.	Unknown effects remain unconfirmed. Do not issue a second payment or incompatible deployment.
H03. Retry or replace worker	Controller uses the remaining time, cost, and retry allowance.	Replacement must already have suitable authority or proceed to H04. Stop stale workers from acting.
H04. Restore authority	Preauthorized recovery role authenticates replacement code or participant control and applies bounded permission changes.	Lost authority cannot be restored by elapsed time alone. If no valid recovery route exists, record the capability as unavailable.
H05. Verify capability	Runner or operations worker tests the restored key, service, budget, or endpoint under its actual permission.	Failure returns to a permitted retry or reaches the recovery deadline.
H06. Resume or close	Controller rechecks the original action's current prerequisites, then resumes it once or records a closed attempt or continued restriction.	Preserve accepted payment obligations and incident evidence. Restored infrastructure does not make a stale candidate eligible.

Provide separate gas funding within an operating allowance. A gas funder pays transaction costs without receiving release authority. An empty allowance needs a named funding source or an explicit inability to execute. The controller cannot create ETH from an approved budget number.

Keep incident and recovery capacity outside discretionary attack-search allowances. Before depending on cloud-level shutdown controls, verify what the chosen provider actually offers and how quickly its cost records update. Local job limits are enforceable sooner than delayed billing data.