ai newsDi., 27. Okt.
EilmeldungChatGPT serves 800 million users from one Postgres primary. Here's how 🐘

An AI Agent Needs Its Own Identity to Be Governed

An AI agent should not inherit authority from the employee who started its task. That shortcut makes the system look simple in the access-control diagram. It also hides the most important question in an investigation: Which actor actually made this decision and called this tool? An employee may ask

dev.toDienstag 12:10 · 27.10.2 Min. Lesezeit

Posted on Oct 27 • Originally published at shyam.kubeify.com

An AI agent should not inherit authority from the employee who started its task.

That shortcut makes the system look simple in the access-control diagram. It also hides the most important question in an investigation:

Which actor actually made this decision and called this tool?

An employee may ask an agent to “prepare the customer renewal.” The agent might then retrieve account data, query pricing systems, draft a proposal, and initiate a workflow. Those actions are not the employee’s actions repeated at machine speed. They are actions taken by a delegated system with its own context, tools, and decision path.

If the logs record only the employee, governance loses the agent’s behavior inside the delegation.

A governable agent needs an identity that can be carried through three points:

This does not mean creating an unlimited identity for every software component. It means making the agent a distinct actor within a bounded chain:

Employee request → Agent identity → Task scope → Tool action

For example, an agent authorized to summarize internal account data may not automatically be authorized to export that data, modify a customer record, or send an external message. The employee’s permissions should not silently expand the agent’s authority.

A team gives an agent access to a shared service account because it is faster than designing delegated permissions. The agent can now call several systems, but the resulting log says only that the service account acted. The original task, the agent version, the requested scope, and the policy decision are missing or disconnected.

First, the system cannot reliably prevent an action outside the task. Second, a reviewer cannot reconstruct whether the action was expected, induced by untrusted input, or simply the result of excessive authority.

Can your team answer what this agent was allowed to do before it acted, not just what it did afterward?

If the answer depends on reading application logs across multiple systems, identity is already too weak.

The goal is not to slow every agent down with a human approval. It is to ensure that autonomy remains attributable and bounded.

An agent that cannot be identified cannot be meaningfully authorized. An agent that cannot be authorized cannot be safely trusted.

Learn more about AXEC and schedule a meeting

Quelle: dev.to (dev.to). Original öffnen