- Treat every AI agent, bot and automation as a separate service identity. Do not let it quietly share an employee's account.
- Review the owner, business purpose, data, permissions, expiry date and activity log for each connection. High-risk access needs a shorter review cycle.
- Test the off-switch. You should be able to revoke the agent's access and show what it did without hunting through several dashboards.
Many companies now review who can use their software. That review often stops at people. It can miss bots. It can miss file-moving workflows. It can miss an AI agent linked to a shared drive. Those systems can read data. They can take actions too. They need their own place in the review.
Call these systems non-human identities. It is a plain term for an account or credential used by software instead of a person. The label matters because it changes the question. Do not ask only, “Who has access?” Ask, “Which system has access, who owns it and what can it do?”
This is not a reason to block useful automation. It is a way to keep its access visible. NIST's current work on software and AI agent identity focuses on identifying agents, controlling delegated rights, logging actions and tracking data flows. The UK's NCSC makes the same basic point for cloud services: service identities need strong authentication and a managed credential lifecycle.
Start with a list, not a new security tool
Begin with the services your team already uses. Look in your identity provider. Check the automation platform and SaaS admin pages. Read team documentation. Add every integration that can sign in. Include tools with an API key, a token or a browser connection. Include test tools that people forget after a trial.
Give each item one row in a simple register. It does not need to be fancy. What matters is that someone can answer the same six questions for every connection.
| Record | What to write down | Why it matters |
|---|---|---|
| Identity and owner | The service account name and a person who is responsible for it | Someone can explain or remove the access |
| Job and systems | The exact task, source data and destination | Scope stays tied to a real need |
| Access granted | Read, create, send, change, delete or admin access | Risk is visible before an incident |
| Credential and expiry | How it signs in, when the token expires and how to revoke it | Old access does not live forever |
| Logs and review date | Where activity is recorded and when the next check is due | You can investigate and reassess it |
A useful register describes actual access, not a sales claim. “Connected to Google Workspace” is too vague. “Reads the labelled support folder” is useful. “Creates a help-desk draft and cannot send” is even better. This detail also makes a vendor conversation easier. See our software vendor security evidence guide when a tool's controls are unclear.
Give the agent its own identity
A common shortcut is to connect a tool with an employee's account. It feels fast. It also makes the record hard to read. The person may change roles. The person may leave. You may not know which automated work will break or keep running.
Use a separate service account or app identity when the service supports it. Give that identity only the permissions the job needs. A reporting agent may need read access to one data set. It probably does not need to change billing, invite users or delete files.
This is the same least-privilege idea used for people. Least privilege means the smallest set of access needed to do a job. It reduces the harm if a token leaks or a tool behaves in an unexpected way. NCSC guidance says services and data should be available only to an authenticated and authorised user or service identity. Its cloud guidance also calls for service credentials that can be rotated and revoked.
Review risk before you review everything
Not every connection needs the same effort. A bot that posts a daily public weather note is different from an agent that can search customer records and send email. Review the highest-impact connections first.
Use three simple factors. Check the data it can read. Check the actions it can take. Check how far a mistake can spread. A connection with personal data needs closer attention. So does one with payment controls, admin access or publishing rights. A read-only connection to a small internal folder may be checked less often.
Set a calendar date for the next review. Tie it to a change too. Review again when a new data source is added. Also review when the tool, owner or permission changes. The NCSC's recent zero-trust guidance calls for access that is explicit, narrow and checked again. It covers private apps, SaaS and cloud services. In practice, a one-time approval should not be the final check.
Make the owner confirm four things
Ask the named owner to confirm four points. Is the job still needed? Is the access still the minimum needed? Is the activity log working? Can the team revoke the connection quickly? Keep the confirmation short. A long form gets ignored.
Owners should not rubber-stamp the request. Show them the actual app. Show the permission level and last activity date. Show the data it touches. If the owner cannot explain the access, pause the connection. If a tool has no clear owner, it should not keep a sensitive permission.
This is different from the first pilot. In an early pilot, a human should approve important actions while the team learns the tool. Our guide to piloting an AI agent safely explains that starting point. A recurring access review is the next operating habit once the tool remains in use.
Test the off-switch before you need it
A register is only useful if the team can act on it. During the review, try a safe removal drill. Revoke a test token. Or disable a non-production connection. Confirm that the tool stops working. Confirm that its activity is visible in the expected log.
Do not run this drill against a critical production workflow without a plan. Use a test account first. You can also use a maintenance window or a reversible permission. Write down the exact steps. Name the admin who can take them. Note any business effect. This turns “we can remove it” into a known process.
Also check what happens when a person leaves. Removing the owner should not remove the evidence. It should either transfer responsibility to another named person or trigger a review. This joins the same lifecycle work that matters for employee access. It complements the passkey and recovery checks in our SaaS renewal checklist.
Keep logs that answer simple questions
You do not need to read every event each day. You do need enough evidence after something goes wrong. Which identity made the request? What data did it reach? Which action did it take? Was a person involved in the approval?
NIST's concept paper highlights logging and transparency as a way to link automated actions to the correct non-human identity. Keep the log location in the register. If the product does not provide useful logs, record that gap and decide whether the task is still suitable for the access it needs.
A small review that teams can keep doing
Start with the five most powerful connections, not every app at once. List them, name owners and check their effective access. Then repeat the same format each quarter or after a major change. The goal is not perfect paperwork. It is to prevent invisible access from becoming permanent by accident.
AI agents make this work more urgent because they can join several systems together. But the solution is familiar: clear identity, narrow rights, active ownership, useful logs and a tested way to remove access. Those controls help with bots, scripts and workflow tools as well.
Sources and further reading
- NIST NCCoE: Software and AI Agent Identity and Authorization concept paper
- UK NCSC: Cloud Security Principle 10 — Identity and authentication
- UK NCSC: Zero Trust Network Access guidance
- NIST: Zero Trust Architecture project overview
Frequently asked questions
What is a non-human identity?
It is an account, credential or token used by software instead of a person. Examples include service accounts, automation bots, API clients and AI agents.
Should every AI agent have its own service account?
Use a separate identity when the service supports it, especially for work that reads sensitive data or takes actions. It makes ownership, limits and removal clearer.
How often should we review an agent's access?
Set a risk-based schedule. Review high-impact access more often, and review again whenever the agent gains a new tool, data source, owner or permission.