Should Your AI Agent Log In With Your Account?
Agent identity is standardizing fast — here is the 30-minute account, permission, and log cleanup a small team can do this week.
Agents are doing real work inside small teams now. A coding agent opens pull requests, a research agent fills spreadsheets, a support agent digs through the shared inbox. And in most small companies, all of it runs while logged in as the founder. Recent industry movement suggests this has shifted from a someday problem to a this-week problem: NIST has been gathering industry input on how agent systems should be identified, authenticated, authorized, and secured, and Singapore's IMDA published a governance framework for agentic AI earlier this year built around accountability, transparency, human oversight, and data governance. It sounds like enterprise talk, but it reduces to one small question: whose identity is your agent working under?
Why give an agent its own account at all?
With a shared login, you lose two things at once: the ability to know who did what, and the ability to cut access without cutting a person off. The keyword in this year's agent identity work is delegation — keep the human and the agent as separate identities, and record that the agent acted on the human's behalf.
Concretely: if your coding agent runs as you, every commit, branch deletion, and deploy carries your name. Three months later, nobody can answer "who changed this setting?" Give the agent its own account and the log reads "Jane requested → devbot executed," and when something breaks you revoke one bot key instead of resetting a human's credentials.
Most teams skip this step not because they lack time, but because they think of an agent as a tool. Operationally, an agent is not a tool — it is an account with permissions. Unlike an app on your laptop, it signs in under your name, reads your data, and changes things. Picture the account setup a new hire gets on day one; an agent needs the same checklist.
What should a small team change first?
There is no single dominant standard yet — in practice teams use a mix of JWT-shaped tokens with custom claims, mTLS certificates, and cloud-managed identities. That is actually freeing: you do not have to wait for convergence. Build these five habits this week and you can migrate to whichever standard wins.
- One account per agent. Create bot users like devbot or support-bot instead of lending a human login. Slack, GitHub, Notion, and Google Workspace all support bot or service accounts.
- Scope permissions to the job. Not "read and write everything" but "this one repository," "this folder only," "read-only." Avoid long-lived keys with no expiry.
- Separate the irreversible. Payments, refunds, bulk sends, and deletions should not sit in the agent's default credential. Route them through a human-approved path.
- Split reading from writing. Any agent that consumes text other people wrote — email, GitHub issues, web pages — is exposed to prompt injection. Let one identity read and a different one write.
- Rehearse revocation. Write the key-revocation steps on one page and actually run them once a quarter. A procedure you have never executed will not work on the day you need it.
Does this cleanup help revenue too?
It does. Access control, audit trails, and data location are already standard questions in B2B security reviews, and teams using agents now get asked about agent permissions on top of that.
Even a three-person team can close a security review with a single page listing every agent, its permission scope, and how long logs are kept. Answer "we run everything on the founder's account" instead, and a great product still loses a month in procurement. So the task for this week is small: write down every agent currently logged into your systems — usually fewer than five. Split off the ones with delete or payment rights first, and thirty minutes today removes your single largest exposure.