AI agents need their own identity: why employee logins are a bad shortcut

Reception connects a new appointment agent to the calendar. The fastest route is obvious: use an employee’s existing Microsoft or Google account. Approve OAuth, verify that the agent can read and write, and the pilot is live.

Three months later that employee leaves. Their account is disabled. The automation stops — or an old token keeps working and nobody can confidently say which automated processes still depend on it. In the audit log, every action also looks as if that former employee personally performed it.

That is not primarily an AI-model problem. It is an identity problem.

An agent that independently reaches into CRM, calendars, storage or APIs should, where the platform allows it, use its own technical identity: a service account, managed identity or comparable workload-identity mechanism. Provider terminology varies. The operational principle is the same: the automation is not “Anna” or “the owner”. It is a named machine actor with its own access and lifecycle.

An AI agent service account makes permissions governable

Permissions are much harder to control when several automations borrow one human identity. You may have role settings, but months later it becomes difficult to distinguish which process performed an action and which credentials can safely be revoked.

NIST’s Zero Trust guidance treats identity as a core input to access decisions. SP 800-207A extends zero-trust access thinking to applications and services in cloud-native environments. Microsoft’s managed-identity guidance similarly treats a workload identity as separate from a normal human account.

For an SME, the payoff is not theoretical. If a booking agent has its own identity, you can disable that agent, narrow its scope or search its activity without locking a receptionist out of her own workstation.

Confirmed fact: mainstream identity architectures support non-human or workload identities and granular access decisions.

Recommendation: give every production automation that acts independently a clearly named technical identity, plus a human owner responsible for the process.

What breaks when an agent works “as an employee”

The first issue is excess privilege. An owner’s account may see email, invoices, staff documents and shared storage. A booking agent may need two calendars and three CRM fields. Reusing the human account often starts the project with far more access than the use case requires.

The second issue is attribution. A log says “maria@example… changed appointment”. Was it Maria, the AI agent, a background script or another integration using the same token? The answer matters when a customer disputes a change.

Third comes offboarding. People change roles, take leave, reset passwords and leave companies. A production workflow should not be invisibly tied to those events.

Fourth is containment. If activity looks suspicious, you want to isolate the agent quickly. With shared credentials, revoking access may also interrupt a person or several unrelated workflows.

Imagine a garage assistant that takes a web enquiry and places a tentative slot in the workshop calendar. Its useful permissions might be calendar read, tentative-event write and narrow CRM access. There is no operational reason for it to inherit the workshop manager’s entire mailbox.

A machine identity is not just another username

Creating [email protected] and giving it administrator rights solves very little. The identity becomes useful when it is treated as a small, dedicated work account.

A practical setup sequence is:

1. Define one purpose per identity. Prefer agent-booking-prod over a catch-all ai-master.
2. Grant only the scopes the workflow needs. Separate read from write; avoid whole mailboxes or drives when a smaller resource can be addressed.
3. Assign a human business owner and technical owner. One owns the process; one can change credentials and platform configuration.
4. Design the credential lifecycle. Prefer managed credentials where supported; otherwise document secure storage, rotation and expiry.
5. Test revocation. Disable the identity in a controlled test and verify that the agent can no longer execute.
6. Make attribution visible. Audit and business logs should identify the machine actor, not only the end system it touched.

Separate test and production identities as well. A sandbox agent using live customer permissions is not meaningfully sandboxed.

Delegation, awkward SaaS products and break-glass access

Not every small-business SaaS product supports proper workload identity. Some expose only ordinary user accounts. In that case, a dedicated technical user with minimal rights, a clear name and no everyday interactive use is often a better fallback than borrowing a real person’s login.

Delegation is also useful when an agent acts on behalf of an employee. Keep the agent’s own identity, but record whose authority it is operating under and which approval or rule granted that authority. You then retain both pieces of information: the technical actor and the business principal.

A break-glass path should exist in the other direction too. If the machine account fails, a human must be able to continue the essential process. That does not mean sharing the agent password around the office. It means knowing how to take over bookings, tickets or quotations manually.

Human handover also applies to access expansion. If the agent reaches a legitimate task that requires a permission outside its normal scope, it should not silently grant itself more access. Route the task to the owner.

The smallest safe pilot

Choose a workflow with limited downside. Create a dedicated identity and grant exactly the access needed for that path. Do not make the agent temporary admin “until the setup is finished”; temporary privileges have a habit of becoming permanent.

Run three deliberate tests: one permitted action, one denied action and a complete revocation. Then inspect the logs. Can you tell, without reconstructing several systems, which agent touched which record and when?

Five useful pilot metrics are actions with unambiguous agent attribution, denied access attempts outside scope, time required to revoke the identity, manual permission exceptions per period, and the share of credentials with defined expiry or rotation.

The decisive test is not whether the demo works. Most demos can make a calendar event. The better test is whether you can stop one agent in minutes without disabling an employee or breaking unrelated automations.

A separate machine identity does not make an AI agent inherently safe. It gives the company a controllable object for permissions, audit, lifecycle and shutdown. That is a much stronger foundation than a clever workflow running forever under somebody’s personal account.

Our guide to permissions and audit logs covers what an agent may do. The agent inventory records where it runs. A dedicated identity joins the two by making that inventory entry technically stoppable.

Sources

• NIST SP 800-207A
• NIST SP 800-207
• Microsoft Entra — Managed identities

---