Agent Identity Is Now a Leadership Decision

The development worth watching

On September 29, 2026, NIST’s National Cybersecurity Center of Excellence announced a summary of public feedback on software and AI-agent identity and authorization. Its DevSecOps project will provide the first implementation use case, demonstrating identity and authorization within software development. This is ongoing implementation work, not a completed certification program or a new universal compliance mandate.

Source: NCCoE: September 2026 agent identity and authorization project update →

A familiar identity problem in a new interface

An August NIST discussion warns against giving agents a person’s credentials and highlights the accountability problems that follow. It argues for treating agents as distinct entities with their own identifiers, credentials, and entitlements connected to the people or systems operating them. Existing identity and authorization approaches, including OAuth and SPIFFE, can support parts of that foundation.

Source: NIST: Why agentic AI needs a strong identity foundation →

Translate the technical question into a business decision

The leadership question is not whether a product includes an agent dashboard. It is whether the organization can explain a consequential action after it happens. A purchase, a production change, or a document disclosure should have an intelligible chain from the requested task to the authority used to complete it.

Consider a hypothetical software team using an agent to prepare a dependency update. Reading a repository, opening a proposed change, approving that change, and deploying it are four different capabilities. A team that says the agent has developer access has not yet explained which of those capabilities it intends to delegate.

Ask the project owner to describe the permitted outcome in ordinary language before choosing permissions. That conversation often exposes an unnecessary capability earlier than a technical access review would. It also makes the approval understandable to people responsible for the business consequences. These are proposed operating practices, not claims about a particular vendor’s implementation.

Build an authority record that survives a handoff

A useful record should be short enough for an owner to maintain and specific enough for an engineer to enforce. Start with one real workflow rather than attempting an enterprise-wide taxonomy in the first meeting.

• Name the accountable business owner and the technical owner who can suspend execution.
• Identify the agent’s execution identity and the person or system on whose behalf it acts.
• List permitted reads, changes, destinations, and actions that still require approval.
• State when authority expires and what happens when the initiating person changes roles or leaves.
• Identify the evidence that connects an approved request to the downstream result.

Test the boundary, not the promise

Use synthetic records in an authorized test environment to demonstrate the difference between preparing a change and executing it. Ask what happens when the proposed action exceeds the approved scope, when an approval expires, or when the destination changes after review. The useful evidence is the downstream system refusing the unauthorized action, not simply the model saying it understands the policy.

Then rehearse a handoff. If the original owner is unavailable, can a colleague identify outstanding work, remove the relevant access, and determine which actions already completed? A shutdown that leaves queued writes or reusable sessions unexplained is an incomplete operating procedure. Record those gaps as engineering work rather than silently assuming the stop button covers them.

Make the next approval conditional on evidence

For a leadership review, request three artifacts: the authority record, a demonstration of one denied action, and a documented access-removal test. Keep them with the project’s release evidence so that a model, connector, or workflow change triggers a proportionate recheck.

This approach does not require leaders to design an identity protocol. It asks them to insist on an answer to a basic delegation question: what has this system actually been allowed to do? NIST’s current work makes that question timely. The practical next step is to answer it for the agent already closest to a consequential business action.