An agent is an identity: permissions, scope and owner

Quick answer:

While a model only answers, the risk is being wrong. Once it executes, the risk is executing. And what separates the two is not the model: it is the permissions it works with.

Most organisations running agents today deployed them with a human's credential or a shared service account. It works on day one. It stops working the day somebody asks who did what.

The borrowed credential problem

An agent using a person's credential inherits everything that person can do. Not part of it: all of it. If that person is an administrator — and they usually are, because they built the pilot — the agent can read payroll while resolving an inventory issue.

A shared service account does not fix this, it only blurs it. Three different agents on the same credential produce an audit trail where every action looks like it came from the same entity. When something goes wrong, there is no way to know which of the three did it, nor to cut its access without cutting the other two.

Neither setup survives a serious audit. And both are the norm.

Three decisions that change everything

An identity per agent

Each agent gets its own workload identity, separate from any person's. This is not bureaucracy: it is what lets you answer "who read this record?" with a name instead of a shrug.

That identity is issued, rotated and revoked like an employee's. If the agent is retired, its identity goes with it.

Minimum viable scope

You would not give an intern access to the entire HR database; you would give them the tables they need. The same applies to an agent, except the temptation to grant broad access is stronger here, because narrowing it requires understanding the use case.

Scope is defined by object and by action: what it may read, write and execute. A support agent that looks up orders does not need to cancel them. If it can, sooner or later it will cancel one.

A named human owner

Every agent identity has a person attached. Not a department: a person. They approve its scope, receive the alerts and answer for what the agent does.

This is what makes autonomy defensible in front of a risk committee. The point is not that the agent never errs, but that somebody answers when it does.

What changes in practice

With those three decisions taken, capabilities appear that did not exist before:

• Per-agent trail: the audit log says which identity touched which data and when, without ambiguity.
• Surgical revocation: one agent is cut off without affecting the others or any person.
• Periodic scope review: permissions requested for the pilot get reviewed when the agent reaches production, which is when half of them turn out to be unnecessary.
• Real containment: if an agent loops or starts hammering an API, its credentials are pulled without touching the rest of the system.

This connects directly to what we already do in data governance: access policies, sensitive data classification and data governance in Palantir Foundry are the foundation any acting agent rests on.

The four mistakes we see most

1. The agent running on its creator's credentials. Quick to build, impossible to audit.
2. Permissions inherited from the pilot. Broad access was requested for testing and nobody reviewed it at go-live.
3. No assigned owner. When it fails, the conversation starts with "whose was this?".
4. Scope by system instead of by object. Granting access "to the CRM" is not a scope: it is an open door.

How to start without slowing projects down

You do not need a six-month governance programme. You need to start with one agent:

1. Inventory: which agents are running and on what credentials. There are usually more than the platform team thinks.
2. One agent, one identity: start with whichever holds the most permissions.
3. Cut the scope until the agent breaks, then give back only what is essential.
4. Assign an owner and write it where people look, not in an email.
5. Set a review date. A scope with no expiry date grows on its own.

How Galde can help

We treat agent governance as an extension of the data governance an organisation already has, not as a parallel framework. In Palantir Foundry, AIP agents act on the Ontology with permissions per object and per action: we define their identities, their scopes and the ownership matrix, and leave it running with your team trained to maintain it. It is part of our data governance in Palantir line of work.

Conclusion

The debate about agent autonomy is almost always framed in terms of model capability. That is the wrong place to look. An agent with a mediocre model and narrow permissions is a minor problem; an excellent agent holding an administrator's credential is an incident waiting for a date.

Treating each agent as an identity — with its scope and its owner — does not slow projects down. It is what lets you defend them when somebody asks.