AI Agent Identity: Your Next Privileged User May Not Be Human

In brief: AI agent identity is the practice of identifying an autonomous software actor and controlling which systems and actions it may use on behalf of an organization. A useful design separates the requester's authority from the agent's credentials, limits access by task, and records the full chain of actions for audit and incident response.

Your next privileged user might not be a person. It might be an AI agent sorting out a customer record, updating a ticket, or pulling information from a finance system. That can save your team real time. But once the agent starts taking action, there is a question worth asking: what, exactly, have we allowed it to do?

That question lands squarely in identity and access. A person may set the goal, but the agent still needs credentials, tools, and permission to act. If those permissions are inherited from a broad service account or a human's session, a single useful workflow can quietly acquire far more authority than anyone intended.

Give the agent an identity, and clear limits

Traditional identity programs already manage employees, contractors, applications, and service accounts. Agents add a harder question: who is responsible when the software chooses several steps to complete a request? You need to tell apart the person who asked, the agent that acted, the tool it used, and the system that let the action happen.

NIST's National Cybersecurity Center of Excellence addressed this directly in its February 2026 concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization, which frames identity standards and access practices as issues for agent adoption. It is a concept paper, not a mandatory control set. The practical point is straightforward: know which agent acted, set limits on what it can do, and be able to trace its work.

A valid login is only the beginning

A valid token tells a system that a credential was accepted. It does not establish that every action taken with that credential was appropriate. Consider an agent told to prepare a renewal summary. Reading a contract may be necessary; changing vendor banking details is not. If both are possible with the same credential, the workflow has an authorization problem even if the login is secure.

Define permitted actions at the workflow level. Limit resources, operations, data scope, and time. Require explicit approval for sensitive changes. Keep secrets out of prompts and logs. Rotate credentials and remove access when the workflow ends. These are familiar least-privilege principles, but agent-driven action makes exceptions harder to see.

Make it possible to follow what happened

When an employee changes a record, the organization expects to know who did it and when. For an agent, leaders should also be able to reconstruct the request, agent version, tools invoked, permissions used, approvals obtained, and resulting change. Logs dispersed across a model provider, orchestration layer, SaaS application, and API gateway can make a single action difficult to trace.

The practical test is simple: could your team explain an unauthorized change without guessing which account or workflow caused it? If the answer is no, deployment speed is outpacing governance.

Five questions before broader deployment

1. Which agents exist, who owns each one, and how are they retired?
2. Does each agent have its own identity, or does it use a shared human or service credential?
3. What systems and actions are explicitly allowed, and what requires approval?
4. Can security staff connect a business request to every downstream action?
5. What happens when a tool, permission, or underlying model changes?

Start with an inventory of the agents already in production or pilot. Map identities, tokens, connected systems, data classes, and consequential actions. Then prioritize workflows by the potential business impact of a mistaken or compromised action. An agent that drafts a summary deserves a different control design from one that updates financial records.

Build controls that work in real life

The first design decision is whether an agent receives a distinct identity at all. A shared integration account may be convenient, but it makes the activity of several workflows look like one actor. A personal token inherited from an employee can be worse: the agent may retain access through a session that was issued for a very different task. Separate identities and short-lived credentials make it possible to change one workflow without disabling every other one.

Next, define the boundary at the level of actions. "Access to CRM" is too coarse. Can the agent read an account, write a note, merge records, export contacts, or change the owner? These actions have different consequences. The permitted set should reflect the business purpose and, where technically possible, be enforced by the application or an intermediary rather than only by instructions in a prompt. Prompts can guide behavior; they are not a substitute for access control.

That distinction matters when an agent receives untrusted material. A document or web page might contain text that attempts to redirect its behavior. If the agent has a broad credential, the consequences of following that instruction grow. Constraining tools and requiring approval for high-impact actions reduces what a mistake or malicious instruction can accomplish.

Let it research before you let it change things

Many agents need to explore information before producing a recommendation. That does not mean they need write access while exploring. An initial read-only phase can collect facts, draft a proposed change, and show a human precisely what would be altered. After approval, a narrower execution step can perform the change with a limited credential. This design is not right for every workflow, but it is a practical way to distinguish analysis from action.

For actions that cannot easily be undone (sending a payment, deleting records, granting privileges, or distributing sensitive information), define an explicit human decision point. Record what the approver saw, what they approved, and whether the executed action matched the approved proposal. An approval button with no understandable summary is weak evidence of meaningful oversight.

Put real people in charge

Every deployed agent should have a named business owner and technical owner. The business owner explains why it exists and what success looks like. The technical owner maintains permissions, integrations, logging, and incident response. Both need a review trigger when the agent's tools, purpose, model, or data sources change. A pilot that gains new capabilities without review can quietly move outside its original risk assessment. (For the broader accountability question, see Agentic AI Governance: Who's Accountable When an AI Agent Makes a Bad Call?)

Retirement deserves the same attention as onboarding. Remove tokens, revoke connections, preserve necessary audit records, and verify that scheduled jobs are no longer invoking the workflow. Otherwise an agent that no longer has a business owner may continue to act through a credential nobody remembers.

A useful initial deliverable is an agent register with purpose, owner, identity, connected systems, allowed actions, approval gates, logs, and retirement or review date. It need not be elaborate. It does need to be maintained as the environment changes.

What to measure

Count agents with distinct identities, workflows using shared or human credentials, sensitive actions requiring approval, and actions that can be traced end to end. Review exceptions and failed authorization attempts. The aim is not to produce a decorative dashboard. It is to know whether the organization can answer the two questions that matter when something goes wrong: what could this agent have done, and what did it actually do?

What this means for technology leaders

The goal is to use agents confidently and keep them under control. Treat identity and authorization as architecture decisions made before scale, not cleanup after a pilot becomes indispensable. Agent access is one of the technology decision trends we expect to shape the year ahead, and it belongs in any identity and access review. MALA can help map the access path and compare practical controls across your current environment before teams commit to a broader rollout.

Executive takeaways

• Inventory agents as distinct actors, each with a named owner.
• Separate authentication from authorization: a valid login does not make every action appropriate.
• Make every consequential action attributable, from business request to system change.

Frequently asked questions

Is an AI agent a service account?

An agent may use service credentials, but its delegated objective and tool choices call for finer accountability than a traditional service account.

Should every agent action require a human?

No. Use risk-based approvals for high-impact changes while constraining routine tasks through narrow permissions.

Where should the review start?

With existing identities, tools, tokens, owners, and audit logs for the agents already in production or pilot.

Before expanding agentic AI, map the identities, permissions, systems, and data your agents can reach. Pressure-test the architecture with MALA.

About the author: Eric Anderson is the Founder and President of MALA Technology Advisors. After two decades working with organizations ranging from early-stage startups to Fortune 500 enterprises, he saw the same pattern repeat: significant technology decisions being made without independent, vendor-neutral expertise at the table. He founded MALA to close that gap, and now leads its advisory practice across cybersecurity, cloud, AI infrastructure, and technology procurement.