IDENTITY
Give every agent, model, service account and responsible owner a traceable identity. Distinguish the agent from the person or organisation operating it.
A nine-part operating framework for making AI agents identifiable, bounded, observable, interruptible and accountable throughout their working life.
Give every agent, model, service account and responsible owner a traceable identity. Distinguish the agent from the person or organisation operating it.
State the business purpose, accountable owner, approved users and decisions the agent may support or take.
Apply least privilege to data, tools, actions, spend and duration. Never grant unrestricted access to sensitive or critical systems.
Record inputs, authorised sources, versions, tool calls, outputs, decisions and material state changes.
Observe behaviour, exceptions, data access, failure patterns, drift and policy breaches against defined thresholds.
Define conditions that stop, contain or escalate the workflow instead of allowing uncertain action to continue.
Give a named person enough information, time, competence and authority to challenge, approve, reject, correct or stop.
Support immediate suspension of credentials, tools, delegated authority and sessions; preserve the reason and scope.
Retain proportionate evidence to reconstruct what happened, who authorised it and how incidents and changes were resolved.
The reviewer sees the relevant evidence, uncertainty, prior actions and consequences—not only a recommendation.
The workflow allows genuine scrutiny by someone who understands the decision and can investigate exceptions.
The person can stop, override, correct, revoke or escalate before a consequential action becomes irreversible.
Automatic approval, habitual rubber-stamping or intervention after the consequence has occurred is not meaningful authority. The appropriate control depends on the use case, affected people, law, risk and reversibility.
| Control question | Evidence expected | Failure response |
|---|---|---|
| Can the organisation identify the agent and accountable owner? | Registry entry, owner, purpose, version and environment. | Do not authorise operation. |
| Is authority explicit and current? | Approved purpose, action boundary and expiry/review date. | Stop or renew through approval. |
| Are permissions least-privilege? | Data/tool scopes, credentials, spending and rate limits. | Reduce or revoke access. |
| Can actions be reconstructed? | Protected event, source, tool-call and decision records. | Contain until observability exists. |
| Are monitored signals tied to action? | Thresholds, alerts, owner and tested response. | Escalate; do not merely log. |
| Do exceptions stop unsafe progression? | Known failure states, containment and fallback. | Fail safely and route to review. |
| Is human intervention meaningful? | Named role, evidence view, time and override ability. | Redesign the decision gate. |
| Can authority be revoked immediately? | Kill/suspend path, credential revocation and tested recovery. | Do not deploy with critical access. |
| Is assurance repeated after change? | Change record, retest, incident learning and review schedule. | Return to bounded operation. |
Sources reviewed 19 September 2026. References include guidance, research and a clearly labelled draft concept paper; this framework does not claim certification or legal conformity.
SOS designs configurable, bounded AI workflows around identity, permissions, evidence, exceptions and accountable human decisions.