What Is an AI Agent?

Document: Architecture, definitional Status: Draft — restructured per external review, blucity-docs#31. Not yet re-verified end-to-end; treat evidence tags below as the current claim, not a closed review. Depends on: core-object-model.md, contract-model.md, receipt-provenance-model.md Required by: OSSA manifests, DUADP node registration, Gas City projections, Drupal AMCS agent config Evidence date: 2026-09-03. Every external claim below carries a source and a date. Re-verify before citing.

---

Purpose

The word "agent" is now applied to chatbots, cron jobs, RAG pipelines, and autonomous systems that spend money. That ambiguity is not a vocabulary problem, it is a governance problem: a thing you cannot define, you cannot scope, authorize, audit, or revoke.

This document separates three things that a single prior draft blended together, per the review filed as blucity-docs#31:

1. DESCRIPTIVE DEFINITION       what an agent IS, independent of Bluefly
2. ADMISSION STANDARD           what Bluefly requires before treating an agent as admissible
3. IMPLEMENTATION PROFILE       how Bluefly actually builds this (OSSA/DUADP/DID/Cedar/Gas City)

Each normative claim below is tagged with its evidence class:

INDUSTRY_CONVERGENCE            multiple independent sources agree
BLUEFLY_POLICY                  this estate's governance requirement, not an industry fact
BLUEFLY_IMPLEMENTATION_CHOICE   how Bluefly chose to build it; alternatives existed
ASPIRATIONAL                    designed, not yet running
PROVEN_IN_RUNTIME               executed and observed, cite the receipt/incident

It is definitional only. Runtime topology belongs to the Gas City and Oracle architecture documents, discovery belongs to DUADP, and the agent contract itself belongs to OSSA.

---

Part 1 — Descriptive Definition

Evidence class: INDUSTRY_CONVERGENCE except where marked otherwise. This part does not encode a single Bluefly policy choice.

The descriptive definition

An AI agent is a software actor that pursues a goal by dynamically choosing its own steps and tool calls, and exercises meaningful control over how it accomplishes the task.

Agent
  goal_directed:  pursues an objective, not a fixed script
  self_directed:  selects its own steps and tool invocations at runtime

Two properties, both required, both descriptive of what makes something an agent rather than a workflow. Whether the agent may act — take effects outside its own context — is a separate question, addressed below as EFFECT_AUTHORITY, not folded into the definition itself.

Why this changed from a five-property bundle. An earlier draft required effectful as a defining property, alongside delegated and bounded. That contradicted this estate's own autonomy model: an L0 system (§ Autonomy, below) is advisory-only by design — it never takes effects outside its own context — yet it is unambiguously an agent under any reasonable reading, including this estate's own autonomy scale. Requiring effectful to be an agent excluded the estate's own L0 tier from the definition of "agent." That is an internal contradiction, not a policy choice, and it is fixed here by treating agency and effect authority as separate dimensions:

AGENCY          = goal_directed AND self_directed        (is this an agent at all?)
EFFECT_AUTHORITY = NONE | REVERSIBLE | GATED | APPROVED | DELEGATED   (what may it actually do?)

An agent can have full agency and EFFECT_AUTHORITY=NONE — a research/planning/recommendation agent that never mutates state outside its own context. That is still an agent; it is simply one with no standing effect authority.

delegated and bounded — acting under a named principal's authority, and being scoped and stoppable — are real and important, but they are admission requirements this estate imposes, not universal properties of "agent" as a word. They are moved to Part 2.

What is not an agent

The most useful line in the current literature is Anthropic's, and it is architectural rather than marketing. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths." Agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." Both are agentic systems; only the second is an agent. (Source: Anthropic, "Building Effective Agents," see References. INDUSTRY_CONVERGENCE for the workflow/agent split itself; this is one vendor's framing, not a surveyed cross-vendor consensus — see the open research item below.)

Applied here, the following are not agents, and must not be registered as OSSA agents or catalogued in gc-agents.md:

Thing	Why it is not an agent
Prompt chain, routing, or evaluator-optimizer pipeline	Predefined code path. It is a workflow.
Chat interface over a model	No dynamic control over its own steps.
MCP server	A tool surface. It is invoked, it does not decide.
A DUADP registry row	A projection of a definition, not an actor.
A Gas City formula or order	Instruction to an agent, not the agent.
Scheduled job that calls a model	Predefined path, no dynamic control.

Calling a workflow an agent inflates the governance surface for no benefit. Calling an agent a workflow understates it, and is the more dangerous error.

Open research item, not yet done: the definition above rests primarily on Anthropic's framing plus one arXiv survey. A defensible canonical definition should compare NIST, OpenAI, Google, Microsoft, the Linux Foundation/A2A project, and academic agent literature for their common properties, and state COMMON_PROPERTIES_ACROSS_DEFINITIONS= rather than treating one vendor's framing as settled industry consensus. This document does not claim that survey has been done.

Anatomy: identity is four layers, not one

The most rigorous current survey of agent identity ("AI Identity: Standards, Gaps", arXiv 2604.23280, April 2026) separates four layers of non-human identity. This decomposition is adopted here because it explains why a single credential never answers "who did this."

model-level      trained weights, architecture, training provenance
                 persists across deployments, does not uniquely identify an instance

agent-level      system prompt, persona, tool grants, credentials
                 mutable, and the layer prompt injection attacks

workload-level   ephemeral runtime instance credential (SPIFFE SVID and similar)
                 identifies the running process, not the intent

delegated-level  authority derived from a human or organizational principal
                 carried by OAuth tokens or capability documents

The paper's framing is worth internalizing: identity is "the continuously estimated correspondence between declaration and observation, bounded by confidence." Valid credentials are necessary and not sufficient. A hijacked agent presents perfect credentials.

In this estate, OSSA is the declaration layer, receipts are the observation layer, and trust tier plus policy evaluation is the confidence layer — see Part 3.

Open gap, named and not solved: the four layers above are not yet joined to Bluefly's actual identity primitives (GitLab service accounts, Gas City workload identities, OSSA agent identities). See "The principal problem" in Part 2.

Autonomy is several axes, not one ladder

Do not classify systems as "agentic" or "not agentic," and do not rank them on a single ladder. An earlier draft used a single L0–L5 scale that conflated six different things — whether an action occurs, whether it is reversible, whether policy gates it, whether a human approves it, whether it runs under a standing delegation, and its scope ceiling. Those are orthogonal. Two real agents — one with high planning autonomy but policy-gated, no standing approval; another with low planning autonomy but a standing delegated write grant — cannot be ranked against each other on one ladder without losing information the governance layer actually needs.

Classify each action class, not each system, on independent axes:

DECISION_AUTONOMY   how much of the plan/step selection is the agent's own choice
EFFECT_AUTHORITY    NONE | REVERSIBLE | GATED | APPROVED | DELEGATED | UNBOUNDED
REVERSIBILITY       is the effect inside a revision-controlled or otherwise undoable boundary
HUMAN_GATE          NONE | NAMED_APPROVER | STANDING_GRANT
DELEGATION_DEPTH    how many hops from the ultimate principal authorized this action
SCOPE_CEILING       the widest boundary this action class is permitted to touch

EFFECT_AUTHORITY=UNBOUNDED (no scope ceiling at all) is not permitted in this estate under any combination of the other axes — that constraint is BLUEFLY_POLICY, not descriptive of agents in general.

This maps onto the operating model already in force: human approval is a fence, not a default. A standing delegated grant (HUMAN_GATE=STANDING_GRANT) is the normal case for work inside an agent's defined authority. A named-approver gate is reserved for genuine boundary crossings. Derive risk from the combination of axes, not from a single ordinal level.

Where the industry actually is, as of September 2026

The connective layer converged fast. The accountability layer did not.

Layer	Standard	Status as of 2026-09-03
Tool invocation	MCP	Spec revision 2026-07-28. Moved to stateless request and response, added RFC 9207 issuer validation, bound client credentials to issuing server, deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, formalized an extensions framework including Tasks.
Agent to agent	A2A	v1.0 released 2026-04-09, hosted by the Linux Foundation, 150-plus participating organizations. Introduced signed Agent Cards for cryptographic identity verification.
Workload identity	SPIFFE / WIMSE	Production ready for workload identity. Does not carry delegated human authority.
Delegated authorization	OAuth 2.0 / 2.1	Partial. Fails on multi-hop delegation. OpenID on-behalf-of flows are one hop only. Token exchange (RFC 8693), GNAP, and capability/macaroon-style models are candidate fixes not yet compared here — open research item.
Composite agent auth	IETF AIMS draft (draft-klrc-aiagent-auth-00)	Draft. Its Security Considerations section still reads TODO.
Portable identity	W3C DID and Verifiable Credentials	Framework available, implementations emerging. This estate has adopted DID/VC as its portable identity layer (Part 3) without a documented comparison against SPIFFE, OIDC subject identities, X.509/SVID, OAuth client identities, or signed Agent Cards as alternatives — flagged as an open architecture decision, not a settled inevitability.
Output provenance	C2PA	Available, regulatory-driven adoption.
Supply chain	SLSA, Sigstore	Available for model and pipeline attestation. Scoped to software; does not cover prompts, skills, or MCP servers as supply-chain artifacts — open gap, see Part 3.
Revocation	CAEP	Available, push-based continuous access evaluation.
Government guidance	NIST CAISI AI Agent Standards Initiative, NCCoE "Software and AI Agent Identity and Authorization"	Directional. NCCoE concept paper published 2026-02, comment period closed, project in "Reviewing Comments". No implementation guidance yet.
Risk catalog	OWASP Top 10 for Agentic Applications v1.0 (2025-12-09)	Diagnostic, not a protocol.
Policy enforcement	Cedar / OPA-Rego / Zanzibar-OpenFGA	This estate has chosen Cedar (Part 3) without a documented comparison against these alternatives — open architecture decision.

NCCoE's working definition is worth quoting because a federal buyer will eventually quote it back: software and AI agents are "systems that have the capability for autonomous decision-making and taking action to operate with limited human supervision to achieve complex goals."

What none of it provides yet

The same survey names five gaps. They are the honest reason a definition alone does not make an agent safe, and they scope what a governance layer has to do.

1. Semantic intent. Cryptographic correctness does not imply semantic correctness. No mechanism verifies that an agent's reasoning is genuine rather than hijacked.
2. Recursive delegation. No production protocol proves which human authorized which agent at the third or fourth hop. Mandatory scope attenuation per hop remains pre-production.
3. Identity integrity. Three live attack shapes: puppeteering (injection corrupts the agent while credentials stay valid), cloning (identical weights run as unlimited concurrent instances), impersonation (replicated credentials in a delegation chain).
4. Governance opacity. Reported confidence in agent governance far exceeds actual monitoring of deployed agents. Over-strict enforcement produces shadow agents that route around sanctioned infrastructure.
5. Operational sustainability. Verification overhead at real agent scale is unmeasured. Universal per-call cryptographic verification may not be affordable.

Gap 3 (cloning specifically) is a named, unsolved problem for this estate — see Part 3. Gap 4 is why enforcement must be usable. Gap 5 is why verification is tiered by risk rather than applied uniformly.

Threat surface the definition has to survive

OWASP Top 10 for Agentic Applications v1.0, published 2025-12-09. Listed here because each item is an argument for one clause of the admission standard in Part 2.

ASI01 Agent Goal Hijack. ASI02 Tool Misuse. ASI03 Identity and Privilege Abuse. ASI04 Agentic Supply Chain. ASI05 Unexpected Code Execution. ASI06 Memory and Context Poisoning. ASI07 Insecure Inter-Agent Communication. ASI08 Cascading Failures. ASI09 Human-Agent Trust Exploitation. ASI10 Rogue Agents.

ASI06 is the one that most directly shapes architecture, and it is under-specified below relative to its actual severity. Persistent agent memory is an attack surface with a long fuse: a source poisoned in one month can fire in another, triggered by something unrelated, with nothing anomalous visible at any single moment. The better the memory, the better the target. Given this estate's use of QMD, RAG, and vector-store retrieval, this is one of the largest actual threat surfaces in the system and arguably deserves its own companion standard covering MEMORY_PROVENANCE, MEMORY_EXPIRATION, TRUST_TIER, WRITE_AUTHORITY, SOURCE_IDENTITY, POISONING_DETECTION, CROSS_AGENT_MEMORY, REVOCATION, DELETION, and VECTOR_STORE_INTEGRITY — none of which is resolved here. This is the case for treating context as a supply chain with custody and trust tiers, and for preferring short-lived task workers over long-lived accumulating ones.

ASI04 (Agentic Supply Chain) also names a gap this document does not close: MCP tool identity, provenance, version, scope, and side-effect class are not modeled anywhere in this estate today. An agent can be perfectly identified and correctly delegated while invoking a compromised or substituted MCP server, and nothing in Part 2 or Part 3 currently detects that.

---

Part 2 — Bluefly Admission Standard

Evidence class: BLUEFLY_POLICY throughout. Nothing in this part is an industry fact; it is what this estate requires before treating something that meets the Part 1 descriptive definition as admissible.

Admissible vs. merely an agent

An actor may fully satisfy the Part 1 descriptive definition of an agent without satisfying this estate's admission requirements. Such an actor is an agent — it is simply not an admissible agent within the Bluefly estate.

This replaces an earlier, weaker phrasing ("is not an agent under this standard") that quietly defined rogue or unauthorized agents out of existence by definitional fiat. A rogue autonomous system with no bounded authority is still an agent; it is an unauthorized one. Calling it "not an agent" understates the threat model rather than strengthening it — an unauthorized agent is exactly the kind of thing a governance layer has to detect and stop, and a definition that reclassifies it as a non-agent gives that detection nothing to look for.

Admission requires all five of:

Agent, admissible in this estate, additionally:
  delegated:   acts under authority traceable to a named principal
  bounded:     has a scope it cannot widen and a stop condition it cannot ignore
  identified:  populates the required-fields block below
  governed:    subject to Cedar policy evaluation before each effectful action
  accountable: emits a receipt for its execution

The principal problem

The descriptive definition requires "authority traceable to a named principal," but "principal" is underspecified once delegation is recursive — and this estate's own multi-hop delegation gap (Part 1, gap 2) makes that underspecification a live risk, not a theoretical one. "Principal" must not be one undifferentiated concept. It decomposes into at least:

ULTIMATE_PRINCIPAL     the human or organization at the root of the delegation chain
IMMEDIATE_DELEGATOR    whoever granted authority to the current actor, directly
EXECUTING_WORKLOAD     the actual running process/session carrying out the action
AGENT_DEFINITION       the OSSA manifest declaring what this agent is and may do
SERVICE_ACCOUNT        the platform-level identity (e.g. GitLab) the workload authenticates as
CREDENTIAL             the specific token/key presented for a given call

Concrete mapping, worked as an example (not yet fully verified end-to-end — flag anything below not confirmed against the actual live configuration):

ULTIMATE_PRINCIPAL   = Bluefly.io (the organization)
IMMEDIATE_DELEGATOR  = Thomas @ Bluefly.io, or a named agent one hop up the chain
AGENT_DEFINITION     = the BLU OSSA manifest
EXECUTING_WORKLOAD   = a Gas City session running that manifest
SERVICE_ACCOUNT      = the GitLab service account the workload authenticates as
CREDENTIAL           = the specific token bound into that session's environment
POLICY_PRINCIPAL     = whatever identity Cedar evaluates policy against for this action

This mapping is illustrative, not a verified inventory. The actual GitLab service-account work in progress at the time of writing should be reconciled against this exact set of layers rather than left as a separate, unjoined effort — that reconciliation has not happened yet.

Required fields for any agent in this estate

An agent that cannot populate these is not admissible, independent of whether it is technically capable of acting.

identity      GAID, resolvable DID, signature, lifecycle state         [ASPIRATIONAL, see Part 3]
principal     the named authority this agent acts for, per the layer breakdown above
grant         scoped capability set, with an explicit ceiling
autonomy      per-action-class axes (Part 1), not a single ladder value
policy        Cedar policy set evaluated before each effectful action
stop          STOP_CONDITION and TIME_BOX
receipt       emits both receipt forms, see Part 3

Two distinct receipt artifacts exist and must not be conflated — see Part 3 for both.

Every active agent additionally answers MVP_BLOCKER, EXPECTED_VALUE, NEXT_PROOF, TIME_BOX, STOP_CONDITION, per the operating model. Those are economic bounds, and they are part of being bounded, not separate from it. Economic authority specifically — spend limits, API budgets, infrastructure cost ceilings — is named here but not further specified; it is an open item.

Lifecycle

The required-fields block above lists lifecycle state but no lifecycle model has been specified. This is a real gap, not an oversight to paper over:

DRAFT → REGISTERED → ACTIVE → SUSPENDED → REVOKED → RETIRED
                            ↘ COMPROMISED

Undefined and unresolved: who transitions state, what happens to outstanding credentials on suspension or revocation, what happens to active sessions when their agent definition is revoked, what happens to discovery (DUADP) entries, and what happens to receipts already emitted under a since-revoked identity. Until these are specified, "revocation" is aspirational rather than operational — see Part 3's known-gaps section.

Human delegation is named, not modeled

"Named principal" and "human gate" are necessary but not sufficient — they say an authorization exists, not how it was granted. Unresolved: who created a given grant, how, when, for how long, whether it is subdelegable, and what specific high-consequence actions it covers (spend money, publish, deploy, delete, contact people externally). This is the actual heart of agent governance and it is not modeled in this document today.

---

Part 3 — Bluefly Implementation Profile

Evidence class: BLUEFLY_IMPLEMENTATION_CHOICE unless marked ASPIRATIONAL or PROVEN_IN_RUNTIME.

The chain

DEFINED         OSSA manifest is the sole authoritative agent definition
DISCOVERABLE    DUADP resolves it, and discovery is not execution
VERIFIABLE      DID/GAID resolves, signature and lifecycle check out        [ASPIRATIONAL]
GOVERNED        Cedar policy evaluates the action, fail closed
ACCOUNTABLE     execution emits a receipt

DISCOVER
  → RESOLVE DID/GAID
  → VERIFY SIGNATURE + LIFECYCLE
  → VALIDATE OSSA
  → EVALUATE CEDAR/GOVERNANCE POLICY
  → IMPORT/PROJECT
  → OPERATOR OR POLICY-GATED EXECUTION
  → GAS CITY SESSION/FORMULA
  → RECEIPT

Ownership boundaries that follow from this chain, and that the chain exists to protect:

• OSSA defines the agent. Gas City agent.toml, Drupal config entities, and DUADP registry rows are projections of the OSSA manifest, never independent sources of truth.
• DUADP discovers and resolves. It must not acquire execution DAG semantics.
• MCP and A2A invoke. They are transport. Neither decides whether an action is permitted, and neither currently establishes tool-server identity or provenance (Part 1, ASI04 note).
• Cedar evaluates policy. A Cedar ALLOW/DENY is a decision, not enforcement by itself. This estate has not yet documented where the corresponding enforcement points (PDP/PEP placement) actually live across GitLab, Drupal, MCP, A2A, and Gas City, how policy context is assembled, how stale policy is handled, how delegation attenuation is represented in a Cedar request, or how the policy version that produced a decision gets attached to the resulting receipt. That is an open architecture item, not resolved by this document.
• Gas City executes. It is an execution projection, not a definition authority.
• Drupal is the business and content authority and the first-class customer product substrate. Per the Drupal Gravity guardrail it must not become the owner of universal agent identity, cross-runtime discovery, generic policy engines, or orchestration.

Identity: DID, GAID, and what is not yet justified

This estate requires a resolvable DID plus a GAID (Gas-City/Bluefly Agent ID) for the identity required field. Two things are asserted here without full justification, and are named as open rather than papered over:

• Why GAID if DID already exists? Not documented anywhere in this estate today. Before treating GAID as settled, this needs: why a second identity namespace is necessary alongside DID, the GAID-to-DID mapping, the global-uniqueness rule, and rotation/migration/collision handling for the case where one agent definition has multiple DIDs or multiple deployments.
• Why DID as the portable-identity layer at all, rather than SPIFFE, an OIDC subject identity, X.509/SVID, an OAuth client identity, or a signed Agent Card (A2A's own mechanism, Part 1)? No comparison has been documented. DID is treated in prior drafts as inevitable; it is a choice, and the choice has not been argued.

Model identity

Not currently decided: whether "identity" for a governed agent includes MODEL_PROVIDER, MODEL_NAME, MODEL_VERSION, a model hash where available, system-prompt version, toolset version, policy version, and agent-manifest SHA. If Claude, GPT, Gemini, and a local model can each instantiate the same named agent (e.g. "BLU"), whether that makes them the same agent, different workload instances, different agent versions, or different trust tiers is unresolved. This matters directly for receipt interpretation: a receipt that does not pin model identity cannot later prove which model produced a given effect.

Cloning and concurrency

Named in Part 1 (identity-integrity gap 3) as an unsolved industry problem; this estate has not solved it either. No answer yet exists for AGENT_DEFINITION_ID vs. INSTANCE_ID vs. SESSION_ID vs. WORKLOAD_ID, concurrency limits, session leases, exclusivity, claims, or revocation of a specific clone without revoking the whole agent definition. This matters concretely for Gas City, where multiple sessions can instantiate the same persona concurrently.

Receipts: evidence, not the security model

Two distinct receipt artifacts exist and must not be conflated.

Machine receipt. The Platform Compiler receipt, schema at contracts/schemas/receipt.schema.yaml, types import, compilation, projection, deployment, verification. Immutable, lineage-bearing, stored Beads to Dolt. Defined in receipt-provenance-model.md, which is the sole authority for its structure. Agent execution produces these.

Session receipt. The operator-facing reporting minimum from the operating model: OBJECTIVE= OWNER= AUTHORITY= SOURCE_SHA= ACTION= RESULT= EVIDENCE= NEXT_ACTION= HUMAN_GATE=. Where HUMAN_GATE is not NONE, add EXACT_DECISION= WHY_EXISTING_AUTHORITY_CANNOT_RESOLVE_IT= CONSEQUENCE_OF_YES= CONSEQUENCE_OF_NO=. Defined in Engineering-Standard/glossary/platform-glossary.md.

What a receipt is not. A receipt is evidence produced during or after execution. It answers "what happened, under what declared identity, what evidence exists" — it does not by itself answer "should this have happened." Gaps 1 through 3 in Part 1 (semantic intent, recursive delegation, identity integrity) are exactly why this estate cannot rely on the credential alone and instead also records the receipt — but prevention/authorization (Cedar's decision, before the action) and observation/accounting (the receipt, during or after) are two different layers that must both exist. Treating "the receipt is the unit of accountability" as equivalent to "the receipt is the security model" would be a mistake this document does not make.

---

Part 4 — Evidence Status

What is proven, what is designed-only. Current source and runtime outrank aspirational documentation wherever they conflict with this document.

• VERIFY SIGNATURE + LIFECYCLE is aspirational in the reference implementation. ASPIRATIONAL. Source audit of drupal/duadp (2026-08-24, tracked as ubuntu-7lk2, P1) found federation endpoints registerPeer and receiveRevocation with no auth check, every DUADP route declaring _access: TRUE, and a public_key advertised in the manifest but never used. No signature verification exists in that codebase. Do not describe federation trust as enforced.
• No OSSA to Gas City exporter exists. ASPIRATIONAL. If built, it belongs in the OSSA-owning repo as a thin adapter, not as Gas City source.
• The end-to-end proof has not been executed. ASPIRATIONAL. Publish an OSSA agent in Drupal, expose it via DUADP, resolve the GAID from Gas City, verify OSSA plus DID plus policy, project, execute one bead, return a signed receipt. Until that runs, the chain in Part 3 is a design, not a demonstrated property.
• Lifecycle states (Part 2) are unimplemented. ASPIRATIONAL. No transition authority, credential-revocation coupling, or session-termination coupling exists yet.
• Cedar PDP/PEP placement across GitLab, Drupal, MCP, A2A, and Gas City is undocumented. ASPIRATIONAL where enforcement is claimed; verify per-surface before citing this document as proof any specific surface is enforced.

Nothing in this section should be read as a schedule. It is a record of what is currently true, dated 2026-09-03, to be corrected as each item moves from ASPIRATIONAL to PROVEN_IN_RUNTIME with a cited receipt or incident.

---

Recommended next work, not done here

Per the review this document implements structurally (blucity-docs#31), a targeted research pass on five topics should precede further normative claims in this document, rather than more prose without it: (1) comparative agent-definition survey beyond Anthropic, (2) delegation/authorization alternatives (OAuth token exchange RFC 8693, GNAP, macaroons/Zanzibar-style capability models), (3) the identity/workload/service-account model concretely joined to Bluefly's actual GitLab and Gas City primitives, (4) policy enforcement point-by-point across every surface Cedar is claimed to govern, and (5) lifecycle, memory security, and tool trust as full companion standards rather than named-but-unsolved paragraphs here. This document does not claim that pass has happened.

---

How to use this document

Cite it when a repository, manifest, catalog entry, or customer deliverable uses the word "agent." If the thing in question fails the Part 1 descriptive definition, rename it rather than registering it. If it passes Part 1 but fails Part 2's admission standard, it is an agent but not an admissible one — the gap is the work item, and the correct move is to fix the existing manifest or module rather than create a new one, or to explicitly decline to admit it.

---

References

Verified 2026-09-03.

• Anthropic, "Building Effective Agents". Workflow and agent distinction. https://www.anthropic.com/engineering/building-effective-agents
• "AI Identity: Standards, Gaps, and Research Directions", arXiv 2604.23280, April 2026. Four-layer identity model, standards status table, five gaps. https://arxiv.org/pdf/2604.23280
• NIST NCCoE, "Software and AI Agent Identity and Authorization", concept paper published 2026-02, status Reviewing Comments. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• NIST, AI Agent Standards Initiative. https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative
• Model Context Protocol, specification revision 2026-07-28. https://blog.modelcontextprotocol.io/posts/2026-07-28/
• Linux Foundation, Agent2Agent Protocol project. A2A v1.0 released 2026-04-09. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents
• OWASP GenAI Security Project, "Top 10 for Agentic Applications" v1.0, 2025-12-09. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/

Internal:

• Engineering-Standard/glossary/platform-glossary.md for OSSA, DUADP, AMCS expansions and the layering doctrine.
• Engineering-Standard/architecture/receipt-provenance-model.md for the machine receipt schema, types, immutability invariant, and lineage model. Sole authority for receipt structure.
• Engineering-Standard/architecture/contract-model.md for contract types.
• Engineering-Standard/governance/constitution.md for authority model.
• blucity-docs#31 for the review this restructure implements.