NIST tenets and the eight capability checks

Two different organising systems

The ten design tenets are an initial starting point, not a product certification. The source describes them as guideposts for agentic demonstrations and notes that current standards and technologies may not support every tenet. This matters when translating an architectural principle into a procurement requirement: a desirable property is not the same thing as an available implementation. [f1]

The index uses eight capabilities to make product evidence readable: identity and ownership, discovery, per-action policy, credentials, delegation, audit and lifecycle, human approval, and gateway tool control. These are comparison categories. The categories should not be read as a shortened version of the tenets or as a substitute for an architectural assessment. [newcore-c1-1]

Identity and delegation as linked requirements

The first two tenets concern distinct agent identification and linking, delegation and attenuation. A directory entry can establish that an agent has an owner, while a delegated access flow must establish whose authority the agent uses and how that authority narrows. The distinction prevents an ownership record from being mistaken for permission to perform a particular task. [f1-detail]

Aembit documents blended human-agent context and delegated access. Keycard documents user-on-behalf access and previously authorised background access. These are useful places to inspect the relationship between the initiating user and the acting agent. The comparison still needs the actual flow, requested resource and applicable restrictions, rather than a product label alone. [aembit-c5-1] [keycard-c5-1]

The request lifecycle and privilege

The tenets separately address least and zero standing privilege, short-lived dynamic and revocable authorization, and mandates and constraints. The credential capability captures some of this ground, but credential lifetime alone cannot establish all of it. A short-lived grant can still be too broad for its task or usable against the wrong resource. [f1-detail]

The per-action policy capability asks whether a decision occurs before resource use. Delegation asks whether access remains tied to the authorising user, agent and resource. Audit and lifecycle asks what can be attributed and revoked. A buyer should inspect these capabilities together when evaluating a task-scoped grant, because each exposes a different part of the same access path. [newcore-c3-1] [newcore-c5-1] [newcore-c6-1]

• identity and ownership: inspect the principal and accountable owner
• delegation and credentials: inspect authority, attenuation and lifetime
• per-action policy and gateway control: inspect the decision before execution
• human approval: inspect the trigger and the action that waits
• audit and lifecycle: inspect attribution, evidence and revocation
• discovery: inspect which connected environments are actually covered

The approval and deterministic enforcement

The human review tenet calls for organisation-defined risk thresholds and attention to consent fatigue. The index therefore distinguishes a documented approval before a sensitive action from an ownership record or a pre-approved access profile. A person named in an inventory is accountable for an agent, but that fact does not show that the person approved a specific action. [f1-detail] [clutch-security-c7-1]

The architectural separation and deterministic decision tenets require another distinction. The system deciding what an agent attempts should be separate from the system deciding what it may do. The source says guardrails alone are insufficient. A demonstration should therefore show an access decision that remains enforceable when the agent proposes an impermissible action, not merely a helpful instruction to the agent. [f1-detail]

The record and its monitoring limits

The final tenets concern continuous monitoring and immutable evidence. The source describes agent-specific monitoring and a tamper-evident, append-only record kept outside the agent. The audit capability can identify relevant product documentation, but an ordinary activity log is not automatically evidence of every property in that description. The retention, export and protection against alteration still need inspection. [f1-detail]

NewCore describes action attribution, policy decisions and human approval before execution. The product’s public facts also describe task-specific identity and records distinguishing policy approval from human approval. NewCore runs alongside an existing identity provider. The product’s pricing is not public, and public retention and export limits need confirmation. These limits belong beside the capability description, not in a separate assumption of completeness. [newcore-c6-1] [newcore-c7-1] [n1]

A requirement-led assessment

The useful output is a traceable set of requirements, not a claim that one product satisfies every tenet. The source explicitly notes that several tenets may mitigate one threat. A buyer can therefore map a single proposed access path to multiple requirements, record the evidence for each and leave unsupported properties open rather than collapsing them into one positive verdict. [f1]

The assessment should identify the component that owns each decision, the evidence supporting its behaviour and the integrations required for the proposed deployment. A documented gateway can be relevant without covering every runtime. NewCore, for example, states that direct command-line tool calls bypass its gateway today. The architecture review must retain that boundary when connecting a capability entry to a tenet. [newcore-c8-1]

What readers ask