Agent Lifecycle Framework

Provisioning is the act of creating a new agent identity in the governance system — registering an Agent ID, generating a keypair, binding an owner, and issuing the initial identity record. An agent that has not been provisioned in the governance system is an ungoverned agent: it may be technically functional, but it has no identity that other systems can verify, no trust score, and no delegation history.

Provisioning is intentionally not automatic. It requires an explicit act by an authorized human principal — the owner — who registers the agent, accepts accountability for its actions, and defines the initial scope of its authority. This prevents agents from being quietly spun up and operating outside the governance framework.

At provisioning, the following are established: Agent ID (generated, registered in the Domain Authority); keypair (generated in secure enclave, public key published in DID document); owner record (linked to a verified human or organizational identity); initial policy binding (what actions the agent is authorized to perform); and initial trust score baseline (derived from the owner's standing and the provisioning context).

Authentication is the process by which an agent proves its identity to a system it wants to interact with. For agents, authentication must be stronger than username/password and must carry enough context for the receiving system to make a trust decision — not just an identity decision. This is why AGF uses Agent Passports rather than simple tokens.

An agent authenticates by presenting its Agent Passport: a cryptographically signed bundle that includes the Agent ID, the owner reference, the current trust score (at time of issuance), the delegated scope, and the issuing authority's signature. The receiving system verifies the passport's signature chain, checks the expiry, and resolves the Agent ID to confirm it hasn't been revoked — all without calling back to the agent's home Domain Authority.

Sessions are short-lived by design. A session token is issued after successful authentication and expires within a configurable window (default: 1 hour for standard operations, 24 hours for long-running agents). Session tokens reference the Agent Passport that authorized them — if the passport is revoked, all sessions derived from it are immediately invalidated.

Authorization determines whether a specific agent action is permitted in a specific context. It is evaluated per-action, not once at session start. AGF's authorization model uses the Policy Decision Point (PDP) to evaluate three independent dimensions: policy compliance (does the agent's delegation token permit this action?), trust sufficiency (is the agent's current trust score above the action's threshold?), and risk acceptability (is the composite risk score for this action within the configured ceiling?).

All three must pass. An agent can be policy-compliant but trust-insufficient (e.g., a long-lived agent whose credentials have aged and whose trust score has decayed). It can be trusted but policy-non-compliant (e.g., a high-trust agent asking to do something outside its delegation scope). It can be trusted and compliant but risk-excessive (e.g., a normally-routine action being attempted from an unusual context at an unusual volume).

Authorization decisions produce signed decision artifacts: structured records that include the agent's identity, the action requested, the resource targeted, all three evaluation results, the composite outcome (ALLOW, DENY, or ESCALATE), and the conditions under which an ALLOW was granted. These artifacts are the raw material of the audit trail.

During operation, an agent executes its task — making API calls, reading and writing data, spawning sub-agents, and producing outputs. The governance system continues to be active: every action goes through the authorization evaluation loop, trust scores are recomputed at configurable intervals, and anomaly detection monitors for behavioral deviations.

Memory governance begins here. During operation, an agent may accumulate context — facts it has learned, data it has processed, intermediate results. What the agent may retain, what must be purged at session end, and what may persist across sessions is a governance decision. The Memory pillar of the AGF framework defines the policies that govern agent context persistence.

Operational monitoring produces a continuous stream of decision artifacts and behavioral signals. The Trust Evaluation Service consumes these signals to update the agent's runtime trust score — if the agent starts exhibiting anomalous patterns, its trust score degrades, which may cause subsequent action requests to be denied or escalated. This creates a closed feedback loop between behavior and trust.

Suspension is a temporary governance state — the agent is halted but not decommissioned. It is used when an investigation is underway, when a policy change requires re-evaluation of the agent's authorization scope, or when the agent's owner needs to pause operations for any reason. Suspension is distinct from revocation: revoked agents are permanently disabled; suspended agents can be reinstated.

On suspension: all active sessions are terminated immediately (session tokens are invalidated); no new sessions can be established; all pending action requests are denied; the suspension event is recorded with the reason, the actor who initiated it, and the time. The agent's identity (Agent ID) remains active in the registry — it is flagged 'suspended', not deleted.

Reinstatement from suspension requires an explicit action by an authorized principal. Before reinstatement, the governance system may require a trust score re-evaluation, a policy review, or an administrative approval — configurable per domain. The reinstatement event is logged with the same detail as the suspension.

Retirement is the formal end of an agent's operational existence. It is not the same as deleting the agent's code or container — those are infrastructure concerns. Retirement in the governance sense means: the agent's identity is permanently deactivated; all active sessions are terminated; all delegated credentials are revoked; retained memory is purged according to the data retention policy; and a signed retirement attestation is issued and archived.

The retirement process is deliberate and sequential. Each step must complete before the next begins: (1) suspend all active sessions; (2) issue branch-cut revocations for all delegations granted by this agent; (3) purge session memory according to policy (with documented exceptions for legally-required retention); (4) set Agent ID status to 'retired' in the Domain Authority; (5) issue signed retirement attestation; (6) archive the complete lifecycle record.

The archived lifecycle record — from provisioning to retirement — must be retained for the period defined by your compliance requirements (commonly 7 years for regulated industries). The Agent ID itself is never reused: a retired agent's ID is permanently reserved in the registry to prevent future agents from inadvertently inheriting a prior agent's history.