NIST’s latest agent-identity work brings a practical question into focus: when software acts for your business, can your systems identify it, limit its authority and show what it did?

What changed in September

On September 29, 2026, the National Institute of Standards and Technology published an update on its Software and Agentic AI Identity and Authorization project. Following feedback from more than 600 commenters, its National Cybersecurity Center of Excellence selected its secure software-development environment as the first implementation use case.

The work will demonstrate identifying, authenticating and authorizing agents within the software-development lifecycle. This is an evolving implementation project, not a new certification or a universal compliance requirement. Read NIST’s September update.

The practical warning

In an August 27 NIST article, security engineer Bill Fisher and Digital Identity Program Lead Ryan Galluzzo write:

“Credential sharing is a bad idea in all contexts.”

Bill Fisher and Ryan Galluzzo, NIST, August 27, 2026

Their analysis connects shared credentials, long-lived tokens and broad access with accountability problems. They also caution that excessive approval prompts can train people to approve without thinking. Existing identity and authorization practices offer a starting point, while agent-specific approaches continue to develop. Read the original article.

What this means for a business workflow

Our practical reading is that agent access belongs in the initial project scope. A demonstration can look convincing while leaving unanswered who owns its connections, which records it may reach and how to stop it.

Consider a task description such as “prepare the weekly sales review.” That describes a useful result, but leaves several implementation choices open. Does preparation require every customer record? Can the assistant alter opportunity stages? Where does the finished review appear? Which person checks it?

Answering those questions makes the first deployment easier to price, test and maintain. It also exposes where a requested workflow depends on access that the business has not agreed to provide.

An illustrative access plan

The project brief could define the following boundaries:

  • Input: approved opportunity fields, current activity notes and source references for the selected team.
  • Output: a dated draft in a designated review location, linked to the records it summarizes.
  • Excluded actions: changing deal stages, editing contact details, sending customer messages or creating commercial commitments.
  • Exception: missing or conflicting information is marked for review instead of silently resolved.
  • Owner: a named person maintains the workflow and decides when to pause it.

These are proposed business requirements. The implementation still has to demonstrate that its tools and access settings enforce them. If a connector only offers access broader than the approved scope, the team needs another configuration, a narrower integration or a smaller first workflow.

Ask for evidence at the handoff

Use an approved test environment to check both the intended path and the boundaries. Confirm that the draft reaches its review location. Try a record outside the approved scope and verify that it is unavailable. Check what happens when a source disappears, a service fails or the same task runs twice.

Have the implementer show the business owner where to pause processing and how access is removed. Review a sample activity record together: can the owner understand which task ran, which source it used and what changed? Keep necessary diagnostic information without collecting unrelated private content.

The next decision

Before adding another agent, choose one recurring task and write a short access brief: approved inputs, allowed outputs, excluded actions, review point and owner. Ask the proposed implementation to demonstrate those boundaries as part of acceptance.

This gives the business a concrete decision. It can approve a bounded trial, request a narrower design or defer a workflow whose access requirements are not yet understood.

Where Protocorp fits

Protocorp can help scope the workflow, organize approved information and define review and handoff requirements. Identity controls depend on the selected services and deployment; specialist security review may be appropriate. The NIST material informs this analysis and does not constitute an endorsement of Protocorp or any particular implementation.

Sources

Explore workflow automationDiscuss your workflow