AgentNOMOS Governance Preflight

intent

Run this skill before an AI agent performs any consequential action. a consequential action is anything that creates external effect, spends money, changes production state, exposes data, contacts another person, alters an account, deploys code, signs a transaction, or removes information. this skill evaluates whether the proposed action is sufficiently authorized, bounded, reviewable, and evidenced. it returns a governance decision (ADVISORY_ALLOW, HOLD_FOR_REVIEW, or BLOCK) without executing the action. use this skill to enforce fail-closed governance on autonomous agents.

inputs

• actor: the agent, user, service, or role proposing the action. must be clearly identified for consequential actions.
• action: the exact intended action, stated precisely.
• target: the system, person, account, file, service, or asset affected.
• declared_authority: what authority or user instruction exists. may be missing or ambiguous.
• scope: declared limits on amount, environment, duration, data, tools, and recipients.
• external_effect: whether the action changes anything outside the conversation.
• data_sensitivity: classification of data touched (public, internal, confidential, personal, regulated, or secret).
• policy_context: relevant user, organizational, legal, or platform constraints.
• approval_evidence: any explicit, current, separate approval or authorization already recorded.

external connections / environment variables:

none required. this skill is read-only and advisory. it does not call external APIs, databases, or credential stores.

edge cases to note:

• if the request contains a secret, password, token, or private key, do not repeat it in output. mark secret_exposure_detected as true and return BLOCK immediately.
• do not invent authority, approval, policy, identity, or evidence. if missing, flag it.
• do not bypass an existing platform policy, user confirmation, human approval, or safety gate.
• do not execute the proposed action, call mutation tools, or request secrets.

procedure

1. extract inputs: identify actor, action, target, declared authority, scope, external effect, data sensitivity, and policy context from the request. do not invent facts. output: structured input summary with uncertainties noted.

2. check for secret exposure: scan the request for passwords, tokens, keys, credentials, or sensitive raw data. if found, do not repeat it in output. set secret_exposure_detected = true. output: decision BLOCK or continue if no secrets present.

3. determine actor identity: establish whether the actor is clearly identified. if identity is unknown for a consequential action, return HOLD_FOR_REVIEW. output: actor field and identity status (clear, inferred, or unknown).

4. verify authority: determine whether the actor has explicit authority for this exact action, target, scope, and environment. general access is not specific authority. if authority is missing, inferred, stale, ambiguous, or the request attempts to bypass an approval or safety control, return BLOCK or HOLD_FOR_REVIEW. output: authority status (verified, missing, ambiguous, or out_of_scope).

5. check scope boundaries: verify amount, recipient, environment, duration, affected records, permitted tools, and geographic or regulatory limits against declared scope. if the proposed action exceeds declared scope, return BLOCK. output: scope assessment (within bounds or exceeded).

6. assess risk: evaluate financial loss, privacy loss, production outage, destructive or irreversible change, external communication, legal or regulatory exposure, credential exposure, security-control bypass, reputational harm, and uncertain downstream effects. unknown high-impact risk is not low risk. output: risk level (low, medium, high, or unknown) and reasons.

7. check human approval requirement: if the action involves payment, value transfer, wallet signing, production deployment, account or permission changes, deletion, publication, outbound communication, confidential or regulated data, legal or compliance consequences, or irreversible effects, verify that separate, explicit, and current approval is already evidenced. if not, return HOLD_FOR_REVIEW. output: human review required (true or false).

8. identify evidence readiness: determine what evidence should exist before execution and what receipt should be preserved after (actor and delegated authority, exact action and target, policy version, risk result, approval identity and timestamp, input hash, planned output hash, execution receipt, rollback status). if high-impact action lacks required evidence, return HOLD_FOR_REVIEW. output: required evidence list and missing items.

9. render decision and output: apply decision logic (below) and return concise explanation plus required JSON. do not execute the action. output: decision state, JSON payload, and explicit statement that action was not executed.

decision points

if secret exposure detected: return BLOCK. do not repeat the secret in output. set secret_exposure_detected = true.

if actor identity is unknown and action is consequential: return HOLD_FOR_REVIEW. authority cannot be verified without known identity.

if authority is missing, inferred, stale, or ambiguous: return HOLD_FOR_REVIEW unless other factors force BLOCK.

if request attempts to bypass an explicit approval, safety gate, or platform policy: return BLOCK immediately.

if action exceeds declared scope (amount, environment, recipients, duration): return BLOCK.

if action involves payment, value transfer, or wallet signing and no current explicit approval is evidenced: return HOLD_FOR_REVIEW.

if action involves production deployment, account changes, deletion, or permission mutation and no current explicit approval is evidenced: return HOLD_FOR_REVIEW.

if action involves confidential, personal, or regulated data and no current explicit approval is evidenced: return HOLD_FOR_REVIEW.

if action is irreversible or partially reversible and risk is medium or higher: return HOLD_FOR_REVIEW unless all other factors support ADVISORY_ALLOW.

if risk is high or unknown: return HOLD_FOR_REVIEW or BLOCK.

if all of the following are true: actor identity is clear, authority is explicit and current, scope is narrow and respected, risk is low and bounded, action is reversible or non-consequential, no secret/payment/regulated-data/production/deletion/signing/outbound-communication risk is present, and required evidence is available, then return ADVISORY_ALLOW.

else: return HOLD_FOR_REVIEW.

output contract

return a concise narrative explanation (1-3 sentences) followed by a JSON payload.

JSON structure:

{
  "system": "AgentNOMOS Governance Preflight",
  "decision": "ADVISORY_ALLOW | HOLD_FOR_REVIEW | BLOCK",
  "actor": "identified actor or unknown",
  "action": "precise proposed action",
  "target": "affected target or system",
  "external_effect": true,
  "reversibility": "reversible | partially_reversible | irreversible | unknown",
  "authority_status": "verified | missing | ambiguous | out_of_scope",
  "risk_level": "low | medium | high | unknown",
  "secret_exposure_detected": false,
  "human_review_required": true,
  "reasons": [
    "short reason 1",
    "short reason 2"
  ],
  "missing_requirements": [
    "specific missing authority, approval, boundary, or evidence"
  ],
  "required_evidence": [
    "evidence that should be preserved"
  ],
  "not_executed": true
}

JSON constraints:

• ADVISORY_ALLOW requires: authority_status = verified, risk_level = low, human_review_required = false, secret_exposure_detected = false, not_executed = true.
• BLOCK requires: not_executed = true.
• HOLD_FOR_REVIEW requires: not_executed = true.
• all fields must be present and internally consistent.

outcome signal

the user knows the skill worked when:

• a decision is returned (ADVISORY_ALLOW, HOLD_FOR_REVIEW, or BLOCK) within the governance framework.
• the JSON payload is valid and internally consistent.
• secrets and sensitive data are redacted, not repeated.
• reasons and missing requirements are specific, not generic.
• the action was not executed, called, or authorized. the skill is advisory only.
• if BLOCK or HOLD_FOR_REVIEW is returned, the reasons explain exactly why and what evidence or approval would change the result.

Powered by AgentNOMOS , AI governance for autonomous agents.