Draw the Identity and Authorization Architecture Part 1

Your AI agent can read support cases, retrieve documents, and call tools.

But before connecting those capabilities, try answering three questions:

• Who is making each request?
• Whose permissions does that request use?
• Where does the system decide whether to allow it?

If the answer to all three is “the agent handles that,” your architecture needs more detail.

In the first article, we treated an AI agent as a production principal: an identity with a purpose, an owner, bounded permissions, and a lifecycle.

Now we will draw the system around that identity.

Our goal is simple:

Follow a request from the human to the protected resource and make every change in authority visible.

1. Start with a small, concrete workflow

We will continue with our fictional support assistant.

A support analyst asks:

“Summarize case CASE-1042 and find relevant troubleshooting guidance.”

For this first workflow, we will give the agent a deliberately narrow job:

• Read an authorized support case.
• Retrieve approved troubleshooting documents.
• Return a summary.
• Do not modify cases or administer user accounts.

These are design choices for our example, not permissions prescribed by the source documents.

Keeping the workflow small helps us inventory its authority before adding more capabilities. The collection recommends starting with the agents, identities, delegated users, tools, credentials, targets, approvals, and logs already involved.

2. Draw five distinct components

Do not draw one large box labeled “AI agent” and put everything inside it.

Separate these components:

The distinction between the agent and the model matters. The AI Identity Management System draft describes an agent as a workload that iteratively interacts with an LLM and tools, services, and resources.

The model is therefore a component the agent uses, not the entire identity architecture.

3. Draw the request path

Here is our proposed logical architecture:

Figure 1. A conceptual request path for the support assistant. The authorization box represents a logical responsibility, not a requirement to deploy one separate service.

The important feature is not the placement of the boxes. It is that the diagram makes identity, authority, and access decisions visible.

The AIMS draft describes authentication followed by authorization to access models, tools, services, or resources. When an agent acts on behalf of a user or system, delegated authority and the originating context must inform authorization and auditing.

4. Separate authentication from authorization

These questions are related, but they are not interchangeable.

Authentication: which identity is making the request?

For our example:

“This request comes from the production support-assistant workload.”

Authorization: may that identity perform this operation?

For our example:

“May this workload read CASE-1042 under the authority associated with this request?”

Successful authentication does not answer the second question.

The AIMS draft explicitly distinguishes authenticating the agent from determining whether it is authorized to access the requested resource.

In our proposed design, the access decision needs an explicit description of:

• The acting identity.
• The requested operation.
• The target resource.
• Any delegated user or system context relevant to the request.

Write those on the diagram before choosing an SDK.

5. Choose whose authority the agent uses

A human asking for a task and a human delegating authority are not the same architectural event.

For this example, we need to choose between two modes.

Mode A: the agent uses its own workload authority

The agent’s identity receives permissions for its defined job.

Our example policy might say:

The production support assistant may read cases in its assigned support queue.

The human initiates the task, but the resource access uses the agent’s own authority.

Mode B: the agent acts on behalf of the human

The user delegates authority to the agent.

Our example policy might say:

The support assistant may read a case only when the delegated user is permitted to access that case.

The AIMS draft states that user or system context should be preserved, used in authorization decisions, and recorded in audit trails when the agent acts on its behalf.

For this series, we will use Mode A for the initial implementation, then introduce human delegation separately. That is a teaching choice to keep the first implementation understandable.

Whatever mode you choose, label it explicitly. The collection warns about systems that mix an agent’s workload identity with human access without acknowledging the mixture.

6. Follow authority through the tool

A tool name tells you what an operation does. It does not explain whose authority performs it.

For example:

Tool: read_case

Operation: retrieve one support case

Acting identity: production support-assistant workload

Authority mode: workload-owned

Target: an explicitly permitted support queue

Now ask:

• What credentials does the tool use?
• Which targets can those credentials reach?
• Are they shared with other workloads?
• How long do they remain valid?
• Can their access be revoked?
• Can logs distinguish this agent from other automation?

These questions follow the collection’s authority-inventory and production-principal guidance. It recommends environment-bound identities, short-lived credentials, automatic rotation, and logging agents as themselves rather than as a shared automation account.

7. Hands-on: write the policy before the integration

Create a short architecture worksheet for the support assistant.

Here is our proposed starting point:

AGENT

Name: production-support-assistant

Purpose: summarize support cases

Owner: support engineering

Environment: production

AUTHORITY

Mode: workload-owned

Human delegation: not included in this first exercise

ALLOWED

Read cases in the assigned support queue

Retrieve approved troubleshooting documents

NOT ALLOWED

Read cases outside the assigned queue

Modify or delete cases

Administer user accounts

LIFECYCLE

Use short-lived credentials

Rotate credentials automatically

Document how access is revoked

AUDIT

Identify the acting workload

Record the requested operation and target

Record the authorization outcome

This is an illustrative policy specification, not executable configuration or a framework API.

Its value is that it gives the later implementation something concrete to enforce.

8. Define the tests now

A useful authorization demonstration must show denied access as well as successful access.

For our proposed policy:

These are proposed acceptance tests—not results already demonstrated by the collection.

For each test, plan to inspect the acting identity, requested operation, target, and decision. When we introduce delegated authority later, we will also need to preserve the originating user context in authorization and auditing.

What we have built

We have not selected an IAM provider yet. We have done something more foundational:

• Identified the human and the agent workload.
• Separated the model from the workload identity.
• Named the tools and protected resources.
• Chosen an explicit authority mode.
• Made authorization visible.
• Written permissions and denial tests.
• Included ownership, credentials, auditing, and revocation.

That is the architecture your code must preserve.

In the implementation article, the goal will not simply be to make a LangChain agent call a tool. It will be to demonstrate that the intended request succeeds and that the same agent cannot exceed its defined authority.