Before You Hand an AI Agent the Keys
AI agents now sign in as you. What a dinner-planning agent taught us about agent identity, credentials and access control, and the five questions to ask first.
Every night an AI agent plans dinner for my family. It knows what we like, what flopped last month, what’s left over from Tuesday and what’s on sale this week. It loads the grocery cart and books a pickup time. It has never once scheduled pickup during an Eagles game.
It also holds a set of keys to my family’s life. Building it taught me more about agent identity than most of the vendor material I’ve read on the subject, so this post starts there, then moves to the agents showing up in our clients’ environments, where the stakes are higher and fewer people are approving the list.
What is AI agent identity, and why does it matter now?
An AI agent acts on someone’s behalf: it signs in, reads, writes, buys, sends and merges. Most agents do that with a person’s own credentials, so every system they touch sees that person. AI agent identity is the problem of telling the two apart and controlling what the agent can do. It matters now because personal agents went mainstream in 2026. Meta launched Muse in September, and the response came fast. Amazon blocked Muse from shopping its store. JPMorgan’s CFO warned customers that sharing banking credentials with an agent could leave them responsible for what it does. 1Password launched a product so agents can sign in without ever seeing the password. The organizations on the other end of an agent’s login are already drawing lines. Most businesses haven’t asked the question yet.
The agent that plans our dinners
Mine runs on Muse, the personal agent Meta launched on September 8, 2026. Meta’s own description is short: “It doesn’t just answer questions, it actually does the work.” Here’s the work it does for us.
- It plans the week’s dinners. It reuses leftovers across meals, plans around what’s on sale that week, and remembers what the family likes and what hasn’t worked.
- It plans around our life. It schedules grocery pickup around weekend plans. When the Eagles play a daytime Sunday game, it suggests wings and keeps pickup well clear of kickoff.
- It writes to our family calendar. It does that through a calendar token I created just for this job, which does nothing else.
- It fills the grocery cart. It uses our shared family account at the store, adds the dinner items and schedules pickup. The rest of the family adds breakfast, lunch, the kids’ things and the essentials during the week.
- It asks before it adds anything. I see the full list first. I uncheck the staples we already have, like spices, oil, rice and baking supplies, and note what’s on hand, like eggs, onions and potatoes, so less food goes to waste.
- It notices patterns. “Pop-Tarts are on sale next week and it’s been a minute. Should I add some?” It keeps a rotating fruit list for the kids.
It’s useful, and the productivity gain is real. When I looked at it the way I’d look at a client’s system, I found I’d built three of the right controls without meaning to, and left two gaps I hadn’t thought about.
The three controls I built without meaning to
A scoped, revocable credential. The calendar token was made only for this agent and this one job. If the agent misbehaves, or I stop using it, I revoke that one token. My account password never changes hands, and nothing else breaks.
A hard limit on actions. The agent can load the cart and schedule pickup. It can’t check out. Without checkout, it can’t spend money, so the worst it can do with the grocery account is a strange cart that I’ll see before anyone pays for it.
A person approves before it acts. Nothing goes in the cart until I’ve seen the list. That catches the ordinary mistakes, like staples we already have, and it would catch the stranger ones too.
Meta has built similar ideas into Muse itself. Its announcement says people choose which apps Muse connects to and how much access it gets, that a separate “Sentinel” agent must approve anything Muse sends to the internet, and that Muse “checks with the person before sensitive actions like sending an email or making a purchase.” Those are good defaults. They’re also the vendor’s controls. The three above are mine, and they’d still hold if the vendor’s didn’t.
The two gaps I didn’t close
The store can’t tell me from my agent. The agent uses our shared family account. To the grocery store, every cart change looks like a member of my family made it. If something odd showed up in the order history, the store’s records couldn’t say whether it was me, someone else in the family or the agent. My setup has the same problem every business has when an agent signs in as a person: the logs record the identity, and the identity is ours.
The agent knows a lot about us. Put together, what it holds is a detailed profile: when we’re home and when we’re out, the kids’ habits, our weekend plans, when the house is busy and when it’s empty. Question 8 in our ten questions to answer before an AI-built app goes live is “what would happen to us if it were compromised?” For a dinner agent, I’d never have asked. The answer isn’t nothing.
Neither gap is a reason to stop using it. Both are worth knowing about before you build the same thing at work.
The agent at work has no one approving the list
Here’s the version we see in business. A client runs a code review agent inside its GitHub organization. It’s event driven: when someone opens a pull request, the agent starts a review on its own. If the change passes a predefined bar, the agent merges it into a specific branch on its own.
Compare that to the dinner agent. My grocery agent can’t touch the cart until a person has approved the list, and it can’t spend a dollar. The code review agent needs no person at all to change the code that branch is built from. Code is the higher-stakes cart, and it has no checkout limit.
Automating review is a reasonable thing to want. It does change the questions. What credentials does the agent hold in GitHub? What else could those credentials reach? Who decided what the “predefined bar” is, and can a cleverly written pull request talk the agent into believing it has been met? An agent that reads content from outside the team, like a pull request description, an issue or a dependency’s README, can be handed instructions inside that content. That’s prompt injection, and an agent that can merge code is an attractive target for it. We walk through that attack step by step in how attackers hijack an AI code review agent.
We see a range of this in client environments: agents in development environments with the autonomy to review, build and push code, and plenty of prospects trying commercial and open-source agents to see what they can do. We use agents ourselves. We haven’t yet worked an incident caused by an agent’s credentials. The setups that would make one possible are already common.
The platforms on the other end are drawing lines
In the two months after Muse launched, the companies an agent logs in to started responding.
- Retailers. Amazon blocked Muse from shopping Amazon.com in September. TechCrunch reported that Muse users trying to buy there saw a notice: “Continued access by an unauthorized AI agent violates Amazon’s Conditions of Use, to which our customers have agreed.”
- Banks. On JPMorgan Chase’s third-quarter earnings call on October 13, CFO Jeremy Barnum said some agent services work “through credential sharing,” that the bank has long opposed screen scraping because “it is not secure,” and that if customers give their credentials to an agent and it does something they don’t want, the responsibility falls on them.
- Credential vendors. On October 22, 1Password launched 1Password for Agents. An agent asks for a credential, the person approves on their own device, and 1Password fills it into the sign-in form without the agent ever seeing it. The launch named Muse, OpenAI’s ChatGPT Work and dots, Anthropic’s Claude Duet and Grok Bot among the agents it works with. The press release calls handing a password to an agent “a common shortcut.”
Read together, those three tell you where this is heading. The sites on the far side of a login want to know when an agent is acting, and they want the agent to have its own permission to be there. A shared password is the one approach all three treat as the problem.
Five questions before you hand an agent the keys
Whether it’s a dinner planner or a code review agent, ask these first.
- Whose identity does it use? Its own, with its own account and its own entries in the logs, or a person’s? If it’s a person’s, you won’t be able to tell what the agent did from what the person did.
- What exactly does it hold? List every password, token and API key, with the scope of each and when it expires. “The same access I have” is too much.
- What can it do without asking? Name the actions that need a person’s approval: moving money, merging to a production branch, sending messages outside the organization, deleting anything. Everything else, it can do on its own.
- What does it read that a stranger could write? Email, web pages, pull requests, shared documents and tickets are all places where someone outside can plant instructions. Every one is a way to steer the agent.
- How do you shut it off? Know which credentials to revoke, who can do it, and how fast. If the honest answer is “change my password,” the agent has the keys to everything that password opens.
These are question 10 in our AI app risk assessment template, expanded. The other nine apply to agents too. An agent is still software, and it still needs an owner, logs and least privilege.
Use the agents, and know which keys they hold
Agents are worth using. Mine saves my family real time every week. The goal is agents with their own identities, the narrowest credentials that work, a person approving the actions that matter, and a way to cut them off quickly.
If your teams are running agents with real credentials, in development pipelines, inboxes, ticketing systems or cloud consoles, our AI agent security testing finds out what those agents can reach and what a stranger could talk them into doing. For the rest of the series on AI-built apps, start with The AI Risk We Keep Finding Is the App You Built.
