An access standard for AI agents that sign in for you

On October 22, 1Password released 1Password for Agents. The agent proves who it is with its own digital key. You see which credential it wants and why, and you approve the request on your own device. 1Password then fills the sign-in form, and the agent signs in without receiving the password.

The same day, TechCrunch reported, citing Axios, that U.S. banks have detected agent activity in customer accounts and in many cases can’t tell whether it matches what the customer asked for. Chase told customers to give their username and password to no one.

What brokered sign-in fixes

A password you paste into an agent becomes a shared secret held by software that can store it or send it on. NIST SP 800-171 Rev. 3 covers this under authenticator management (03.05.12), where the discussion calls for not sharing authenticators with others. OWASP’s Securing Agentic Applications Guide gives agents the same advice: prompt for credentials out of band, or integrate with a trusted password manager.

1Password built that advice into a product you can use today. If your team still pastes passwords into agents, this closes that gap.

The two questions it leaves open

The first is attribution. Once the agent signs in, the session belongs to you, and the system records your name for each action the agent takes. NIST SP 800-171 Rev. 3 asks you to tie each user’s identity to the processes acting on their behalf (03.05.01) and to record the identity of each entity in audit records (03.03.02). In its Agentic Identity and Access Management paper from March 2026, CoSAI models agents as distinct identities. It prefers delegation, which keeps both identities visible in the token and the log, over impersonation. The banks in the Axios report are looking at this gap from the other side. They see activity in a customer’s account and can’t match it to a request.

The second is where the data goes. The agent sends everything it reads after sign-in to its model endpoint. If that endpoint sits outside the authorized boundary for the data, the sign-in method doesn’t change the finding. An assessor will check information flow enforcement (03.01.03) and use of external systems (03.01.20), and neither requirement asks how the agent signed in.

I spend the most time on the second question: bringing agents into the workspace while controlled data stays inside the authorized boundary. The agent workflows I build stop at a governance gate when a check fails, and I wrote these access rules the same way. Every grant gets a record and an end date, and if a check can’t run, the agent doesn’t get in.

Three ways an agent can reach a system

You assign each agent one pattern per system and record it in the register.

Pattern A, brokered sign-in. The agent signs in as you through a credential manager, and you approve each use. Logs show you. It fits personal or low-risk accounts, read-only work and data with no handling rules. Skip it anywhere an assessor will test whether you can tell agent actions apart from yours.

Pattern B, delegated identity. The agent has its own identity and receives a short-lived token for each task. The token names both the agent and you, with scopes no wider than the task needs, and the logs show both names. Use it for organizational systems and for any agent that changes data or spends money.

Pattern C, no agent access. The system stays closed to agents. Use it as the default for controlled data until the agent and its model endpoint both sit inside the authorized boundary and your system security plan documents them.

Six questions before any grant

Answer these in writing, in the grant record, before access starts.

1. Where does the model run, and is that inside the authorized boundary for this data?
2. Will the agent only read, or can it write, send, buy or delete?
3. Can the log tell the agent’s actions from yours?
4. Which scopes does it get, and which are excluded?
5. When does access end, and who can revoke it in one step?
6. Which actions need a person every time?

Keep the list in question 6 short: actions you can’t undo, and actions that send information outside the organization. OWASP’s guide warns that people who see too many approval prompts start approving without reading.

What’s in the kit

All three files are free to download at the end of this post.

The Agent Access Standard runs eleven pages. It sets ten requirements and the steps for picking a pattern, and it closes with a crosswalk that maps each requirement to the sources listed at the end of this post. The DOCX is the editable version. Replace each bracketed item with your own.

The Agent Access Register holds one row per grant, with drop-down lists for status, data class, pattern and approval mode. A flag column marks any grant that has expired or has no end date, and any grant that sends controlled data to a model outside the boundary. The summary sheet counts active grants by pattern and each open flag.

How to start

1. Replace the bracketed items in the standard with your organization’s names, roles and systems.
2. Enter each agent already in use as a row in the register, starting with the ones that can reach controlled data. CoSAI’s first implementation phase starts the same way, by discovering and registering every agent.
3. Have your security lead confirm where each agent’s model runs, and close any system where the answer puts controlled data outside the boundary.
4. Review the register on a schedule, and again whenever a vendor changes how its agents sign in.

What to check before you rely on it

The crosswalk is my reading of each source. CMMC Level 2 IDs follow Rev. 2 numbering, because Level 2 still tests the Rev. 2 requirements. The Level 3 column lists the NIST SP 800-172 requirements that apply on top of a Level 2 certification, and leaves the cell blank where none applies. I cite ISO/IEC 42001 by control title only. Check each mapping against your own system security plan and authorization documents before you depend on it. Use the template as a starting point. It isn’t legal or compliance advice.

For the executive who owns AI risk

OMB M-25-21 gives each agency’s Chief AI Officer the AI use case inventory and the job of making sure high-impact AI gets an independent review before anyone accepts the risk. You can use the register to carry that inventory down to a single login. From its summary sheet, you should be able to tell leadership how many agent grants exist and who accepted the risk on each one.

Sources

• NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, May 2024
• CMMC Assessment Guide, Level 2, Version 2.13, September 2024
• CMMC Assessment Guide, Level 3, Version 2.13, September 2024
• OMB M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, April 3, 2025
• ISO/IEC 42001:2023, Artificial intelligence: Management system
• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023
• Coalition for Secure AI (OASIS), Agentic Identity and Access Management, Version 1.0, March 20, 2026
• OWASP GenAI Security Project, Securing Agentic Applications Guide 1.0, July 28, 2025
• 1Password, “1Password for Agents,” press release, October 22, 2026
• TechCrunch, October 22, 2026, citing Axios, on banks detecting agent activity in customer accounts