Skip to content
Agent Security 5 min read

Give AI agents identities you can revoke

Agents that borrow a person's login or a shared service account leave reviewers guessing. Give each agent its own identity, scoped credentials, and a path to revocation.

By Halo Security Engineering

Many AI agents act with borrowed authority. A developer's personal access token sits in a configuration file, a shared service account serves five automations, and an API key pasted into a prompt was never rotated.

When something goes wrong, the log names a person or a generic account. Nobody can say which agent acted, who owns it, or how to stop that one agent without disturbing the others. A distinct agent identity solves this by giving each agent a record of its own.

Three identities that get mixed together

Agent systems involve three kinds of identity, and each answers a different question.

  • User identity. Represents a person and answers who asked for the work. An agent that borrows it inherits every permission the person holds, and the log blames the person for what the agent did.
  • Service account. Represents a shared automation and answers which automation ran. When several agents share one, they share one set of permissions, and nobody owns a single agent's behavior.
  • Agent identity. Represents one specific agent and answers which agent acted, for whom, and within what limits.

Keep the three separate. An agent identity can record the delegating user without inheriting everything that user can do.

What an agent identity carries

An agent identity is a record, and the useful fields are the ones reviewers ask about.

  • Owner. The person or team accountable for the agent, who receives its alerts and answers questions about it.
  • Purpose. What the agent is for, in one sentence.
  • Delegating user. The person on whose behalf the agent acts, when there is one.
  • Boundaries. The models, tools, apps, and data the agent can reach, and the actions it may take.
  • Lifecycle state. Whether the agent is active, paused, quarantined, or retired.

For example, a support team might run an agent that drafts replies from order data. Its identity names the support lead as owner, lists the helpdesk and order apps as its connections, allows reads on orders, and requires human approval before any refund. Each action records the person who asked for the work.

Halo keeps the agent's identity separate from the user's identity, its credentials, its tools, and its action scope. Each can change on its own, and the changes leave a record.

Credentials the agent never sees

A credential that the agent never holds cannot be leaked by the agent. With credential brokering, provider and app credentials stay bound at the gateway, and the agent receives scoped capabilities that name what it may do.

Three things follow.

  1. Leaks have less to leak. An agent that is tricked into revealing its configuration has no raw key to reveal.
  2. Scope is explicit. Each capability names the tool, app, or model and the actions allowed. You can review it the way you review a role.
  3. Revocation is local. Removing a capability at the gateway ends that agent's access. Other agents keep working, and nobody has to hunt for copies of a key.

A scoped capability can still be misused within its scope, so scope needs policy. Tool-level checks and human approval for higher-impact actions cover the cases where permission alone is too broad. The post on an agent's permission as the start of the decision explains why.

An agent that never holds a raw key cannot reveal one, and a capability you can remove is an access path you can close.

Revocation you can test

Revocation sounds simple until someone has to do it under pressure. Decide in advance what revoke means for your agents. It usually includes the following steps.

  • Stop new calls from the agent.
  • End sessions that are in progress.
  • Invalidate its scoped capabilities.
  • Pause scheduled work that would start it again.
  • Hold it in a state where nobody can restart it until a review is done.

In Halo's secure agent runtime, operators can quarantine an agent and release it later. Budgets can also pause new operations or stop active deployments when spend crosses a threshold.

Then test it. Pick a low-risk agent, trigger the revocation, and measure the time from the decision to the last allowed call.

Write down what kept running. Repeat the drill after each significant change in how agents are deployed.

Put the identity in the evidence

Identity pays off when someone investigates. A useful decision record names the agent, the delegating user, the tool or model, the policy version, and the outcome. Reviewers can then filter by agent and see one agent's behavior in one place.

Halo records decisions, approvals, denials, costs, and configuration changes, and audit logs and gateway decisions export as CSV and JSON. Finance teams benefit as well, since cost analytics by agent and model need an owner to point to.

Retire agents on purpose

Agents can outlive the project that created them. A pilot ends, the owner changes teams, and the agent keeps running with its old access.

Treat retirement as a change with its own steps. Revoke the agent's capabilities, stop its scheduled work, close or reassign its budget, and keep its decision records for the retention period your reviewers expect.

Verify closure by testing it. Calls from the retired identity should be denied, and the owner should confirm that nothing still depends on it.

A starting checklist

You can begin with a short list.

  1. List the agents in use, including the ones that individuals started on their own.
  2. Give each one an owner, a purpose, and a boundary.
  3. Move shared keys behind a gateway.
  4. Replace broad permissions with scoped capabilities.
  5. Add approvals for actions with real consequences.
  6. Run a revocation drill and fix what it reveals.

Each step makes the next review cheaper. When something does go wrong, the same record also shortens the response, as the post on responding to an AI agent incident describes.

How Halo helps

Halo separates agent identity from user identity, credentials, tools, and action scope. Its gateways broker credentials so agents receive scoped capabilities and never see raw keys, and operators can quarantine and release agents in the secure agent runtime. Read about agent identity and access or book a walkthrough to trace one agent from delegation to evidence.

  • agent identity
  • credential brokering
  • access control
  • agent security
H

Halo Security Engineering

Halo Security Engineering works on agent isolation, credential brokering, runtime policy, and the controls that keep agents safe.

All articles

Put a halo around the AI your business runs.

See discovery, runtime policy, approvals, and evidence working together on your own use cases.