An agent becomes trustworthy in production only when two questions have precise answers: who is acting, and where is the agent being called? The first answer is the agent identity, the secure account the agent uses when it asks for access. The second is the endpoint, the dedicated web address where requests arrive. Together they turn an agent from a useful piece of code into an accountable service.

The two handles every hosted agent receives

When a hosted agent is deployed, the platform gives it two things automatically: its own identity and its own endpoint. The identity is the account the agent presents when it calls a model, a tool, a database, storage, or another service. The endpoint is the agent’s front door, the address callers use to reach that particular agent.

These sound like operational details, but they define the security boundary. The identity determines what the agent can do. The endpoint determines how others invoke it. If either one is vague or shared carelessly, it becomes hard to answer basic incident questions: which agent did this, who allowed it, and how do we stop only that agent without breaking the rest?

Every hosted agent gets an identity that says what it can do and an endpoint that says how it is invoked. Identity vs Endpoint Identitywho it is Endpointwhere to reach What it can do How it's invoked The badge The front door
Every hosted agent gets an identity that says what it can do and an endpoint that says how it is invoked.

What identity means for software

People usually prove who they are by signing in. Software needs an equivalent. An identity for software is a secure account, like an identification badge, that a program presents when it asks to do something protected.

A service receiving the request checks that badge, decides whether the identity has permission, and records the request in logs. Without an identity, software is effectively anonymous. Anonymous software cannot be granted narrow permissions, and it cannot be held accountable in a useful way. With an identity, each request carries a name that can be allowed, denied, reviewed, or revoked.

📌
Identity is not a label. A display name tells people what something is called; an identity is what services verify before granting access.

Why one identity per agent matters

The shortcut is to let several agents share one identity. It is convenient at first and costly later. A shared identity hides the individual agent behind a common badge, so logs show that the shared account acted, not which agent made the decision.

A dedicated identity per agent gives you three practical controls. First, least privilege: each agent can receive only the permissions it needs. Second, attribution: logs can name the specific agent that made a call. Third, revocation: if one agent is compromised or retired, its access can be removed without disabling unrelated agents.

This is not administrative neatness. It is the difference between security you can operate and security you can only hope is working.

A dedicated identity per agent gives least privilege, attribution, and revocation. One Identity Per Agent Dedicated identityone per agent Least privilegeonly what it needs Attributionnamed in logs Revocationremove just one
A dedicated identity per agent gives least privilege, attribution, and revocation.

Do not confuse agent identity with project identity

Hosted agent systems often involve more than one identity, and mixing them up causes bad permission decisions. The agent identity is the runtime identity. It is the account the running agent uses when it calls models, tools, and downstream services.

The project identity is different. It is used by the platform for infrastructure work, such as pulling the agent’s container image or managing deployment-related resources. It supports the project, but it is not the badge your agent presents while doing its work.

When you ask what an agent can reach, look at the agent identity. When you ask what the platform needs in order to deploy or operate infrastructure, look at the project identity.

  • Use the agent identity to reason about runtime access.
  • Use the project identity to reason about platform infrastructure tasks.
  • Avoid granting application data permissions to the wrong identity.

Acting on behalf of a user, or acting as itself

An agent can use authority in two different ways. When a person invokes the agent interactively, the agent can act on behalf of that user. In that mode, it carries the user’s permissions, subject to the organisation’s policies. The agent is a delegate, not a super-user.

When no user is present, such as in a scheduled task or background workflow, the agent acts as itself. It uses its own agent identity and the permissions granted directly to that identity.

Both modes still need the agent’s dedicated identity for authentication and auditing. The distinction is not whether the agent is accountable. It is whether the source of authority is the user’s permissions or the agent’s own permissions.

With a user present the agent acts on their behalf; alone it acts as itself with its own permissions. Whose Authority User present? Yes No On behalfuser's permissions Acts as itselfown permissions
With a user present the agent acts on their behalf; alone it acts as itself with its own permissions.

What a new agent can reach by default

A fresh agent identity should not be all-powerful, and hosted agents are designed around that principle. By default, the agent can reach the essentials it needs to function, such as calling models through its project and using its own session storage.

Access to your own resources is separate. If the agent needs to read a database, write to a storage account, call an internal application programming interface, or use another protected service, you grant that access explicitly to the agent’s identity.

This makes every extra permission a decision that can be reviewed. It also makes cleanup possible. When the agent no longer needs a resource, remove that permission from that agent rather than hunting through shared credentials or broad service accounts.

✅
The safe default. A new agent should start with only the essentials and earn every additional permission explicitly.
A new agent reaches only essentials by default; access to your resources is granted explicitly. Access by Default Built-incalls models Session storageits own Explicit grantsyour resources default reviewed
A new agent reaches only essentials by default; access to your resources is granted explicitly.

The endpoint is the agent’s front door

The endpoint is the dedicated web address for a specific agent. It is created when the agent is deployed, and it is available as soon as the agent version is active. You do not need a separate formal publishing step before calling the active version programmatically.

The exact endpoint style can vary depending on how the agent is configured to communicate. Some agents may be called through one protocol or integration style, while others expose a different shape. The important design point is simpler: each agent has a distinct address that callers can target intentionally.

A dedicated endpoint and a dedicated identity reinforce each other. The endpoint says which agent is being asked to work. The identity says who that agent is when it reaches outward to do the work.

Decisions this changes for leaders and practitioners

Identity and endpoints are not only platform details. They shape operating policy. A security leader wants to know whether access can be contained. An architect wants to know where boundaries sit. An engineer wants to know which account needs a permission and which URL to call. A risk owner wants to know whether an incident can be reconstructed.

The practical test is straightforward. For each production agent, you should be able to name its identity, name its endpoint, list what the identity can reach, state when it acts on behalf of a user, and revoke that one agent without harming the others.

If those answers are not easy to produce, the system may work, but it is not yet easy to govern.

  1. Does every agent have its own identity, rather than sharing one with other agents?
  2. When the agent calls a service, is it acting on behalf of a user or as itself?
  3. What can the agent reach beyond model access and its own session storage?
  4. Was each extra permission granted deliberately?
  5. Can you disable this agent’s access without disrupting other agents?
⚠️
Governability test. If you cannot attribute and revoke one agent cleanly, you likely have a shared-account problem.

Key takeaways

  • Each hosted agent receives its own identity and its own endpoint when deployed.
  • A per-agent identity enables least privilege, precise attribution, and targeted revocation.
  • The agent identity is the runtime badge; the project identity is for platform infrastructure work.
  • With a user in the loop, an agent can act on behalf of that user; without a user, it acts as itself.
  • A new agent can reach only essentials by default, and access to your resources must be granted explicitly.
  • The endpoint is the agent’s dedicated front door and is available once the active version is live.

Glossary

Identity
A secure account a program presents to prove who it is when requesting access.
Agent identity
The per-agent runtime account used by the running agent to call models, tools, and downstream services.
Project identity
A separate platform-managed identity used for infrastructure tasks such as pulling an image or operating deployment resources.
Endpoint
The dedicated web address where callers send requests to a specific agent.
On behalf of
A mode in which an agent acts as a delegate carrying the permissions of the user who invoked it.
Autonomous mode
A mode in which an agent acts without a user present and uses permissions granted to its own identity.
Least privilege
The practice of granting an identity only the access it needs and nothing more.
Revocation
The act of removing an identity’s access so it can no longer use a resource.
Audit trail
A record of actions that shows what was requested, by which identity, and often under whose authority.