Agent Principal Identity

Status: Standard-only Alpha (v1.0.0-alpha.2)
Last Updated: 2026-03-20
Spec ID: ACGP-7
Normative Keywords: MUST, SHOULD, MAY (per RFC 2119 and RFC 8174)

Abstract

This specification defines the minimum public identity semantics for governed agents in ACGP. It establishes that agent_id identifies the governed agent principal within a deployment-defined trust domain, while agent_label is an optional display field and sender_id remains a transport or runtime sender identifier.

agent_id is the stable governed principal identifier within a deployment-defined trust domain. It is not, by itself, cryptographic proof of identity.

ACGP-7 standardizes identity meaning and governance keying. It does not define cryptographic proof of identity, certificate issuance, federation, workload attestation, or revocation protocols.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1. Scope [NORMATIVE]

ACGP-7 defines:

  • the meaning of agent_id as the stable governed principal identifier
  • the meaning of agent_label as a non-authoritative human-readable label
  • the distinction between agent_id and transport/runtime sender_id
  • the governance-state keying expectations for trust debt, intervention history, review posture, and rate controls

ACGP-7 does not define:

  • identity provider integration
  • signing, PKI, certificate issuance, or revocation
  • workload attestation or hardware identity
  • cross-domain federation or trust discovery
  • new required wire fields beyond the existing ACGP trace model

2. Design Principles [NORMATIVE]

The following principles govern ACGP identity semantics:

  1. ACGP governs an agent principal, not an agent-chosen display name.
  2. agent_id is consumed as a stable governance key within a deployment-defined trust domain.
  3. Human-readable names are useful for operators but MUST remain non-authoritative.
  4. Transport senders and governed principals are related but distinct concepts.
  5. Identity meaning is standardized here; identity proof remains a deployment or extension concern.

3. Identity Model [NORMATIVE]

3.1 Core Terms

agent_id is the stable identifier of the governed agent principal within a deployment-defined trust domain.

agent_label is an optional human-readable display name associated with that principal. agent_label is non-authoritative.

sender_id identifies the transport or runtime sender of a message envelope. It is not necessarily the same as the governed agent principal.

session_id, task_id, trace_id, and runtime instance identifiers are correlation identifiers. They do not replace agent_id as the governance key.

3.2 Assignment Rules

Implementations MUST apply the following rules:

  1. agent_id MUST be assigned by the host runtime, operator, or deployment control plane.
  2. Model or agent logic MUST NOT unilaterally choose its own governing agent_id.
  3. Implementations MUST treat agent_label as optional display metadata only.
  4. Implementations MUST NOT use agent_label as a trust anchor, audit correlation key, or state-storage key.
  5. Implementations MUST NOT infer governing identity solely from a model-selected name, assistant name, or wrapper label.

3.3 Identifier Quality

agent_id SHOULD be stable across sessions for the same governed principal.

agent_id SHOULD be opaque or deployment-scoped rather than human-meaningful when practical.

agent_id MUST NOT embed secrets, credentials, or sensitive personal data.

Example valid forms include:

  • urn:acgp:agent:financeops:prod:7f4c9d2a
  • agent-prod-42c9a7
  • svc://governed-agents/risk-review/primary

4. Wire Semantics [NORMATIVE]

ACGP-7 does not introduce new core wire fields. It clarifies how existing fields are interpreted.

  1. TRACE agent_id identifies the governed agent principal responsible for the traced reasoning or action.
  2. Envelope sender_id identifies the transport or runtime sender of the message.
  3. sender_id and agent_id MAY be the same string in simple deployments.
  4. sender_id and agent_id MAY differ in proxy, sidecar, brokered, delegated, or multi-runtime deployments.
  5. Implementations MUST NOT reject an otherwise valid message solely because sender_id and agent_id differ.

agent_label MAY appear in existing metadata surfaces such as TRACE meta, logs, dashboards, or operator interfaces. ACGP-7 does not require a dedicated top-level agent_label field.

5. Stateful Governance Integration [NORMATIVE]

Per-agent governance state MUST be keyed to agent_id.

This includes at minimum:

  • trust debt state
  • intervention history
  • review posture
  • rate controls
  • any other governance memory intended to persist across sessions or runtimes for the same governed principal

Implementations MUST NOT substitute sender_id, agent_label, session_id, trace_id, or runtime instance identifiers when evaluating principal-scoped governance state.

If a deployment intentionally scopes governance state more narrowly than all runtimes in a trust domain, it MUST still preserve the invariant that the chosen state key represents the governed principal and not merely a display name or transport hop.

6. Conformance Requirements [NORMATIVE]

An implementation that claims conformance with ACGP-7 MUST:

  1. treat agent_id as the governed principal identifier
  2. treat agent_label as non-authoritative display metadata only
  3. preserve the semantic distinction between sender_id and agent_id
  4. key principal-scoped governance state to agent_id
  5. avoid deriving agent_id from agent-chosen names in governed execution paths

An implementation does not satisfy ACGP-7 if it:

  • equates display name with governing identity by default
  • rejects valid messages because sender_id != agent_id
  • keys trust debt or rate limits to session-scoped identifiers instead of agent_id

7. Security Considerations [NORMATIVE]

ACGP-7 defines semantic identity, not cryptographic identity proof.

Accordingly:

  1. Self-presented agent_id values alone are not sufficient trust anchors for deployment security.
  2. Deployments MUST still provide transport authentication, signing validation where required, and operator/runtime controls for assigning or validating governed principals.
  3. Certificate chains, issuer trust, workload binding, and revocation remain outside this specification.

The main security benefit of ACGP-7 is reducing ambiguity in governance state and audit semantics. It does not eliminate the need for deployment trust controls.

For the conceptual deployment-boundary map, see docs/learn/concepts/protocol-boundaries.md.

8. Future Extension Surface [INFORMATIVE]

Future extensions MAY define:

  • signed agent identity documents
  • issuer-backed or operator-backed principal assertions
  • workload identity binding
  • federation and cross-domain trust mapping
  • revocation and rotation workflows for principal credentials

Those capabilities are out of scope for ACGP-7 core semantics.

9. Test Vector Guidance [INFORMATIVE]

Recommended checked-in conformance vectors include:

  1. identity-001.json for valid principal assignment with meta.agent_label
  2. identity-002.json for trust-debt continuity when agent_label changes
  3. identity-003.json for valid TRACE handling when sender_id != agent_id
  4. identity-004.json for principal-scoped rate control across sessions
  5. identity-005.json for audit correlation by agent_id across runtimes and sessions
  6. identity-006.json for rejection of self-named principal assignment