Companies are standing up AI agents the way they once stood up shadow SaaS. Ship the demo. Show a time save. Worry about identity after the CFO has seen the slide. NIST’s Bill Fisher and Ryan Galluzzo spent an August 27 Cybersecurity Insights post saying that pattern is how you rebuild every IAM failure of the last twenty years, only faster.
Stop lending the agent your badge
Security people have said “do not share passwords” since passwords existed. Accountability dies when two actors use one login. That is still true when the second actor is software.
Giving an agent your personal or corporate credentials is already common. It is also how you lose non-repudiation in banking and health. If the log says “Alice approved the wire,” and Alice’s password was sitting in the agent’s config, the log is a story, not evidence.
Treat the agent as its own principal. Unique ID. Own credentials. Entitlements bound to the human or system that owns it. Enterprises and IAM vendors are already building registries, delegation, and policy for that. OAuth 2.0 and SPIFFE cover a lot of enterprise cases. WIMSE and identity-assertion JWT grants are stacking more capability on top. Consumer apps are messier because the company often cannot tell a person from a bot if the bot has the person’s password. FIDO is looking at agent authenticators bound to a user. That work is early. Until the safe path is also the easy path, people will keep pasting secrets into chat.
Long-lived keys are still a dumpster
The fastest way to get an agent talking to a third-party API is a static key or a bearer token that never expires. Fast is the problem. A bearer token does not prove who holds it. Whoever has the string can call the API. Keys are usually fat: all the endpoints, not the three the agent needs. They also show up in config files, markdown, and logs.
This is not a new incident class. Stolen tokens have burned companies for years. Agents just multiply copies and movement. Short-lived agents still get long-lived secrets because nobody mapped credential lifetime to agent lifetime.
The starting kit already exists: OAuth, SPIFFE, JWTs, X.509, sender-constrained tokens such as DPoP. NIST’s draft IR 8587 is about token hygiene for a reason. Dynamic, tight, audience-restricted credentials are available now. Waiting for a perfect agent standard is how keys stay in the repo.
Least privilege was already losing. Agents will finish the job.
Moving off API keys does not automatically give you least privilege. Role bloat and standing access are still normal. Zero trust posters are common. Just-in-time access is not.
Agents make coarse grants dangerous. They follow a goal, not a script. Give them a wide role and they will try tools and data you did not picture, including deleting a repo they were only supposed to read. Give them a tight role and they will still hunt for an orphaned key on the box.
Scope the grant to the business task and the risk you can stand. Then clean tokens everywhere else, because the agent will find the leftover. Rich Authorization Requests let you describe the action instead of a blunt scope. Transaction tokens try to carry context down a chain of calls so rights shrink as they pass. AuthZEN gives policy engines a common API so decisions can sit outside the agent. Use them. Do not wait for the agent to invent a fourth path through finance.
Local laptop agents are convenient and sloppy
Developers like agents on the workstation: slides, spreadsheets, terminal, IDE. Handing that process the local user account means the agent is the user. Commands run with human rights. The org cannot keep a clean inventory of agent identities. Secrets land in files on disk.
Cloud can use hardware roots of trust and tighter boxes. Local will not disappear. If it stays, put the agent in a harness or a locked-down container so it cannot roam the whole machine. Constrain it before the first prompt, the same way you would constrain a cloud workload.
Human-in-the-loop is not a strategy if you train people to click Allow
Binding identity, shrinking delegation, and tight scopes still leave gaps. Teams then add “ask the human.” That works until the agent asks every two minutes. MFA bombing already taught us what happens. People approve to make the noise stop. After that, the click is not consent. It is habit.
MCP-style elicitation can also pull passwords and other secrets into the thread so the agent can impersonate the user. The MCP spec itself warns against using elicitation for sensitive material. Flight-plan style approvals, with the secret stripped out of the prompt, are one way vendors are trying to cut the chatter. Design the human gate for rare, high-impact steps. If every tool call needs a tap, you do not have a control. You have a pop-up farm.
Audit the IAM you have before you scale the agents you want
Fisher and Galluzzo’s close is the least glamorous line in the post and the most useful. Look at current IAM against current standards. The holes you already have will get worse at agent speed. Shared creds, static tokens, fat roles, and approval spam are not “agentic challenges.” They are unfinished homework.
Comments on the NCCoE work can go to AI-identity@nist.gov. More posts and a resource hub are planned. Readers already pushed the next question in the comment thread: identity is not the same thing as authority for a specific action, and authorization at kickoff is not authorization after the agent switches tools mid-flight. That is the work after you stop sharing passwords.
Ship the agent if you must. Do not ship it with Alice’s login and a key that never dies. That is not moving fast. That is taping the badge to the robot and calling it a program.