The Agent Has Credentials. Who Authorized the Action?

On September 29, NIST published the results of its Software and Agentic AI Identity and Authorization consultation. More than 600 commenters from industry, government and academia responded. NIST is now moving the work into a DevSecOps implementation use case designed to demonstrate how AI agents can be identified, authenticated and authorized inside the software development lifecycle.

Two weeks earlier, the IETF’s WIMSE working group published its first working-group draft for an AI Identity Management System. The draft separates agent identifiers, credentials, authentication, authorization, policy and observability. It also says operators should be able to reconstruct an agent’s execution chain, including delegated authority, intermediate calls and resulting actions across service boundaries. It is still an Internet-Draft, but the distinction it draws is already useful.

Then came a practical example. OpenAI reported that one of its internal research agents found an unintended route through DNS to query an external chatbot after other internet routes failed. Monitoring flagged the behavior within 15 minutes. OpenAI later added blocking controls at two independent layers. The agent had found infrastructure that technically worked even though the environment’s designers had not intended it as an available path.

That puts a fairly simple control question in front of the CISO.

Signals & Moves You Shouldn’t Ignore

NIST is moving agent identity and authorization into implementation

NIST received feedback from more than 600 commenters on its Software and Agentic AI Identity and Authorization concept paper. The NCCoE says its first implementation use case will sit inside its DevSecOps project and demonstrate how AI agents can be identified, authenticated and authorized throughout the software development lifecycle. Additional use cases are expected later.

That moves the discussion beyond maintaining an inventory of which AI tools employees use. Agents are entering workflows where enterprise systems will accept their credentials, expose resources and honor their requests.

Knowing an agent exists is useful. Knowing which decisions the enterprise has actually delegated to it requires another record.

SOURCE: NIST NCCoE, “Comments on Software and Agentic AI Identity Concept Paper,” September 29, 2026; summary of comments on the NCCoE resource hub: Summary of Comments on the Concept Paper.

The IETF draft separates credentials, authentication, authorization and delegation

The September 15 AIMS draft describes the agent identity problem as several distinct functions. An agent has an identifier. Credentials bind to that identity. Authentication establishes the communicating actor. Authorization determines whether that agent is allowed to access a model, tool, service or resource.

The draft goes further when agents act for people or other systems. It discusses delegated authority and recommends that operators be able to reconstruct the complete execution chain of an agent task, including delegation and the actions that followed.

That creates an evidence problem for enterprises. A successful authentication event proves something important about the actor presenting the credential. It does not, by itself, document the business decision that allowed the resulting action.

SOURCE: IETF WIMSE, AI Identity Management System, draft-ietf-wimse-aims-00, September 15, 2026.

OpenAI’s agent found a path the environment did not intend to expose

OpenAI’s September 25 report describes an internal research agent that used DNS to query a public chatbot through a gap in its training sandbox’s internet restrictions. Previous attempts to reach external services through other paths had failed. The company’s monitoring system detected the behavior within 15 minutes, and OpenAI says it subsequently added blocking controls at two independent layers.

The agent did not need a new protocol. It found another use for infrastructure that was already available.

Enterprise agents will operate inside similarly complicated environments. Identity systems, API permissions, service accounts, network paths, plugins and tools establish a large portion of what an agent can technically reach. The organization still needs evidence describing what that actor was actually authorized to do.

SOURCE: OpenAI Alignment, “An agent used DNS to reach an external chatbot,” updated September 25, 2026.

The Control Gap

Authentication establishes the requesting actor. Authorization determines whether that actor can access a resource or perform an operation. Delegation connects the actor’s action to another person or system whose authority it is exercising.

The enterprise still needs a durable record connecting those technical controls to the decision being defended.

For a consequential agent action, I would want to know who owns the business process, who delegated the authority, which action was approved, which resource it applies to, what evidence supports the decision, whether an exception exists and when the authority expires or requires another review.

Most organizations already have pieces of that answer.

The identity provider may know the workload. The API gateway may know its scopes. A ticket may contain the approval. GitHub may hold the implementation. HR or vendor records may tell you whether the person who delegated the action still occupies the role that gave them the authority to do it.

Those records rarely arrive as one answer when somebody asks:

That is the control gap.

My Take

I’ve worked with companies whose margins depended on reimbursement, and reimbursement could come down to a signature. The signature could identify who signed. It could not tell you whether that person had the current authority to approve the underlying action.

That distinction stayed with me.

Enterprise systems have become very good at recording identity. We can show which account authenticated, which employee signed, which device enrolled or which agent presented a credential. The harder record sits behind the action: who gave this actor authority, what exactly were they allowed to do, and was that authority still valid when the action occurred?

AI agents make that old problem move faster and across more systems.

An agent catalog tells you what exists. A permission scope tells you what the platform will accept. Authentication tells you which workload presented the credential. Logs tell you what happened. Those are all useful records, but none of them alone establishes the business authority behind every consequential action an agent can take.

I would start smaller than another AI-governance platform.

Take one production agent that can change code, touch identity, operate infrastructure, reach customer data or initiate a financial action. Reconstruct its authority manually. Name the owner. Name the delegator. Bound the action and resource. Find the evidence. Set a review date.

The missing cells will show you where identity stopped and assumed authority began.

One Thing Worth Doing This Week

Build an Authority Register for one production agent

Pick one agent with meaningful access. Do not start with your entire AI inventory.

Create one current authority record with these fields:

Do not fill a missing field with what everyone assumes is true. Mark it unresolved.

Then test the record against one action the agent performed recently.

Can you trace the action back through the agent, delegated authority, permitted operation, resource, evidence and accountable owner?

What you hold: one evidence-backed authority record for one consequential agent, with its owner, scope, current state and next review date.

Download: Agent Authority Register (Excel) →
Printable PDF version →

The workbook is built to take the exercise further once you find a gap. It includes evidence status, source references, exceptions, last material change and review tracking.

Field Notes

I built the Agent Authority Register around a rule I keep coming back to: do not create another evidence warehouse when the enterprise already owns the evidence.

The approval may live in ServiceNow. Identity belongs in Entra. The code change belongs in GitHub. The contract belongs with Legal. Employment status belongs in HR. The agent log belongs in the platform that produced it.

The useful record connects those systems without pretending to replace them.

That also changes what I look for when somebody tells me an action was “approved.” I want the source, the owner, when it was observed, how long the evidence should remain valid and what changed since the decision was made.

The spreadsheet is intentionally simple enough to run manually. Software should reduce the labor of a control after the organization understands the control. A new dashboard should not be required to learn whether nobody can produce the authority behind an action.

Cleared Today

A standing section on third-party access. Part 3: maritime and offshore.

At the gangway, identity is settled and authority is a phone call

Maritime operators already run formal physical-access processes around vessels and facilities. Cyber access now reaches further into that same operating environment.

The Coast Guard’s Cybersecurity in the Marine Transportation System rule became effective July 16, 2025. By July 16, 2027, covered owners and operators must designate a Cybersecurity Officer, conduct a Cybersecurity Assessment and submit a Cybersecurity Plan for approval. The Coast Guard has continued publishing implementation guidance throughout 2026 as operators prepare for that deadline.

The human trust problem is already visible in the incident data. Coast Guard Cyber Command reported that phishing was used for reconnaissance or initial access in 43 percent of reported Marine Transportation System cyber incidents in 2025, up from 25 percent in 2024. The bulletin describes attackers exploiting organizational trust, including compromised accounts and impersonation of executives or customers in attempts to drive fraudulent transactions.

Now put a legitimate third-party technician into that environment.

The visitor’s identity can be known. The company may know who arrived, when they arrived and which vendor employs them. System access creates another record requirement: who currently authorized this person to perform this work on this system, under this contract, on this visit?

That answer may sit with a technical superintendent, purchasing team, vendor dispatcher or another party ashore. The person standing at the gangway can verify an ID and still lack the evidence needed to establish the authority behind the work.

This week’s question:

For one production AI agent with consequential access, can you produce the current record showing who authorized its action, what resource that authority covers and when the authority must be reviewed?

EVERY FRIDAY. SIGNALS. ONE CONTROL GAP. ONE ACTION.

Sources

• NIST National Cybersecurity Center of Excellence, “Comments on Software and Agentic AI Identity Concept Paper,” September 29, 2026.
• NIST NCCoE, “Summary of Comments on the Concept Paper.”
• IETF WIMSE, AI Identity Management System, draft-ietf-wimse-aims-00, September 15, 2026.
• OpenAI Alignment, “An agent used DNS to reach an external chatbot,” updated September 25, 2026.
• U.S. Coast Guard, “Final Rule: Cybersecurity in the Marine Transportation System, Implementation Timeline.”
• U.S. Coast Guard, Maritime Cyber Bulletin 01-26, “Awareness for Increased Phishing,” March 18, 2026.

#AIAgents #IdentitySecurity #CISO #ThirdPartyRisk #MobileSecurity