Agent identities and least privilege: a practical checklist for business

This week's headlines covered Okta Agent SSO, Microsoft Entra Agent ID, runtime authorization gateways, and SDK-level human approvals. The common thread: your agents need their own identities and job-scoped permissions, not borrowed admin credentials.

Here is a practical checklist for a mid-size operator who is not ready for a six-month IAM project but cannot keep sharing one API key across every pilot.

Why shared credentials fail

When every copilot runs as the same service account or personal OAuth token, you lose three things immediately:

• Attribution: you cannot tell which workflow sent the email.
• Containment: revoking access breaks ten unrelated tools.
• Least privilege: the broadest permission wins for all agents.

Survey data cited in 2026 coverage suggests most organizations over-grant AI access relative to human roles, and most cannot trace agent actions to a human sponsor. That is an incident waiting for a calendar invite.

Principle 1: One identity per agent instance

Treat each production agent (or each distinct workflow) as its own principal in your identity system:

• Unique client ID, service principal, or agent user record.
• Display name that humans recognize ("AR collections agent prod").
• Human owner field required at creation time.
• Tags for environment (prod/staging) and data classification.

Okta Agent SSO and Entra Agent ID are vendor implementations of this idea. You can approximate it with named service accounts and a spreadsheet until your IdP catches up, but do not skip uniqueness.

Principle 2: Permissions match the job description

Write a one-page persona before enabling tools:

• Allowed systems (CRM yes, payroll no).
• Allowed actions (read + draft email, not send without approval).
• Row or record limits (no bulk export over N records).
• Business hours or rate limits if relevant.

Map that persona to the narrowest role your platform allows. Microsoft's Dataverse pattern is instructive: create an agent user, assign a dedicated security role, test denied operations, verify audit logs.

Principle 3: Human sponsor and lifecycle

Every agent identity links to a accountable human who can answer:

• Why does this agent exist?
• What happens if it misbehaves tonight?
• Who approves model or prompt changes?
• What is the decommission checklist when the pilot ends?

Decommissioning means revoke OAuth, delete secrets, remove schedules, archive logs, and notify dependents. Agents without sponsors become ghost accounts.

Principle 4: Runtime enforcement, not just provisioning

Directory registration is necessary but not sufficient. High-risk tool calls should pass through a gateway that can:

• Score risk from tool name, arguments, and data sensitivity.
• Pause execution for human or policy approval.
• Deny out-of-scope actions even if the token is valid.
• Emit trace-level logs for auditors.

OpenAI-style interruption/resume flows are the application-layer version. MCP gateways are the infrastructure-layer version. Use at least one.

A two-week rollout plan

Week 1: Inventory and owners

1. Export all API keys, OAuth apps, copilot plugins, and scheduled LLM jobs.
2. Assign an owner and business purpose to each.
3. Flag anything running as a human admin or shared mailbox.

Week 2: Split and scope

1. Create dedicated principals for the top two production agents.
2. Reduce permissions to the minimum that still completes the workflow.
3. Add approval on one sensitive action (payment, external send, delete).
4. Run a kill-switch drill: revoke the agent and time recovery.

You will find edge cases. Document them. Perfect IAM is not the goal. Traceable identities with revocable scope is the goal.

RFP questions to steal

• Does each agent instance get a unique identity in our directory?
• Can we assign separate roles per agent without cloning the whole app?
• Can we pause tool calls pending human approval?
• Can we export a 30-day audit trail per agent principal?
• What happens to credentials when we offboard the agent?

What to ignore

• "We use your SSO" without per-agent principals.
• Super-admin API keys for convenience.
• Identity projects that never connect to tool-call enforcement.

Bottom line

Agent identity is how you make autonomy accountable. One principal per agent, permissions tied to a written job, a human sponsor, and runtime gates on risky tools. That stack scales from a three-person pilot to an enterprise IdP without changing the logic.

Questions on agent IAM for your stack? Reach out and we will point you at the right pattern.

Matt Potter · Swift Media