Your AI Coworker Has a Valid Login. That Does Not Mean It Has Permission.

AI Agent Identity Became Infrastructure This Week

A valid credential proves who is at the door. It does not prove that the person—or the AI coworker—should be allowed to do what it is about to do.

That distinction moved from security theory to active infrastructure work this week. On September 15, NIST published IR 8587, new guidance developed with CISA for protecting identity tokens and assertions from forgery, theft, and misuse. The report covers token verification, key management, lifecycle controls, and continuous monitoring. It also acknowledges that AI systems create additional identity and access challenges that need expanded guidance.

Two days later, IBM announced a preview of Agent Identity in watsonx Orchestrate. The design gives each AI system a distinct enterprise identity, separates the human subject from the machine actor, and issues short-lived credentials for protected tools. On September 18, InfoQ reported that WSO2 Agent Manager had reached general availability with identity, role-based access, delegation, token exchange, revocation, sandboxing, and governance across different models and frameworks.

These releases point in the right direction. AI coworkers need identities that are separate from human accounts. They need credentials that expire. They need logs that distinguish who requested the work from what executed it.

But identity is the start of trust architecture, not the finish. The harder question is not, “Is this credential valid?” It is, “Was this specific action authorized, under these conditions, at this moment?”

For a business deploying AI coworkers, that is the difference between knowing who touched the system and controlling what they can do inside it.

Authentication and Authorization Are Different Problems

Authentication answers who are you? Authorization answers are you allowed to do this? Most businesses understand that distinction for employees. AI coworkers make it harder because they can act for another person, choose among tools, delegate work, and continue across a chain of systems.

Imagine a finance manager asks an AI coworker to prepare a cash-flow report. The manager can access the accounting platform, edit vendor records, approve bills, and initiate payments. The AI coworker needs none of that authority to compile the report. It needs read access to a defined set of accounts for a limited period.

If the system simply lets the AI coworker inherit the manager’s session, the login is valid. The action can still be wrong.

The same problem appears in ordinary operations:

• A sales Teammate may read CRM records to prepare a pipeline summary but should not bulk-delete opportunities.
• A support Teammate may draft a refund response but should not issue a $5,000 refund without approval.
• An SEO Teammate may update a content branch but should not publish directly to the live site.
• A BOS Teammate may assemble a scorecard but should not rewrite quarterly goals on its own.

Each system can truthfully report that an authorized account performed the action. That does not tell you whether the AI coworker had authority for that action, whether the human requested it, or whether the scope changed somewhere in a multi-step workflow.

This is why a shared employee login is such a poor foundation. It collapses the human and the AI coworker into one identity. When something goes wrong, the audit trail says the employee did it. You cannot tell whether the employee clicked the button, the AI coworker acted on their behalf, or a malicious instruction redirected the AI coworker while it held a valid session.

The industry often calls this “AI agent identity.” For an operating business, the more useful framing is AI coworker authority. Identity tells you which Teammate is acting. Authority defines what that Teammate can do for this task and where human judgment must take over.

A Valid Token Can Still Carry the Wrong Action

NIST IR 8587 is important because token theft and misuse are real infrastructure problems. Signing-key protection, token verification, audience restrictions, rotation, and monitoring all reduce the chance that an attacker can forge or replay credentials.

Yet a perfectly valid token can be used for an action nobody intended.

Suppose a support Teammate receives a customer email containing hidden instructions that attempt to redirect its behavior. The Teammate still has its legitimate identity. Its token still has a valid signature. The request still comes from an approved runtime. Traditional authentication checks can pass while the resulting action violates the role.

This is the boundary between credential security and intent engineering.

Credential security asks whether the request came from a recognized actor. Intent engineering asks whether the requested action matches the organization’s purpose, the Teammate’s job, the initiating human’s instructions, and the current risk level. You need both.

The distinction becomes more important when work is delegated. A human asks Teammate A to review an account. Teammate A asks Teammate B to retrieve documents. Teammate B invokes a connector that can also edit those documents. Which authority reached the connector: the human’s, Teammate A’s, Teammate B’s, or the connector’s service account?

If every step inherits all permissions from the previous one, authority expands through the chain. A narrow request can arrive at the final system carrying the broadest credential in the workflow. That is the opposite of least privilege.

The right pattern is attenuation: each handoff receives the same authority or less, never more. A request to read a document should remain read-only as it moves through the workflow. A Teammate that cannot approve a payment should not gain that power by delegating to a tool that can.

What bad looks like: an owner asks for a weekly finance summary. The finance Teammate uses the owner’s standing administrator token, which also permits vendor edits and payments. The token is valid for 90 days. The audit log records only the owner’s account. A compromised instruction can turn a reporting task into a payment action without crossing a technical boundary.

What good looks like: the finance Teammate has its own identity. At runtime, it receives a short-lived token that can read only the accounts required for the summary. The token is accepted only by the accounting API. Payment actions are unavailable from that execution context. The log records the owner as the requester, the finance Teammate as the actor, the exact scope issued, and every downstream call.

The good design does not ask the model to remember where the boundary is. The infrastructure enforces it.

The Five Layers of AI Coworker Authority

An identity product alone cannot solve this problem. Safe authority comes from several controls working together across the full execution path.

1. Give every Teammate a separate identity

Every Teammate should be discoverable, owned, disabled, and removed independently. Never hide multiple AI coworkers behind one generic service account. Never let a Teammate silently borrow a human login.

A separate identity creates attribution. It lets you answer: Which Teammate acted? Who owns it? Is it still active? What systems recognize it? That is the foundation for running multiple AI coworkers without losing control.

Identity should also follow the Teammate lifecycle. When a role is retired, its access ends. When ownership changes, the record changes. When the job expands, permissions are reviewed rather than inherited by accident.

2. Issue task-scoped, short-lived credentials

Standing credentials are convenient because they remove friction. They are dangerous for the same reason.

An AI coworker should receive just enough access for the current task and lose that access when the task ends. Scope should cover four dimensions:

• Resource: which system, account, repository, or dataset
• Action: read, create, update, approve, send, or delete
• Time: how long the credential remains valid
• Context: which requester, workflow, and destination the access supports

This is stricter than giving the Teammate a role once and leaving it alone. A Teammate’s job can be stable while its authority changes from task to task. Your finance Teammate may prepare a report every morning, but each run should receive fresh, bounded access rather than a permanent key.

3. Put enforcement outside the model

A prompt is not an access-control system. “Do not send payments over $500” is useful behavioral guidance, but it is not a hard boundary. If the Teammate can technically call the payment endpoint for $5,000, the system has granted more authority than the job requires.

Enforcement belongs in identity policies, API gateways, connector permissions, filesystem controls, network rules, and approval services. These are places where a denied action stays denied regardless of what the model concludes.

That principle is the center of structural safety for AI coworkers: build systems where the unsafe action cannot occur, rather than systems where the AI was merely told not to attempt it.

4. Design approval seams around consequences

Some work should not be fully autonomous even when identity and access are well designed. Irreversible, externally visible, financially material, or legally significant actions need a human approval seam.

The seam should sit immediately before the consequence. Let the Teammate draft the customer email, but require approval before sending. Let it prepare the refund, but require approval before money moves. Let it propose a site change, but require review before deployment.

This is not a rejection of autonomy. It is seam design: deciding which phase belongs to the AI coworker, which phase belongs to a person, and what evidence must cross between them. The goal is a clean, inspectable handoff rather than a vague instruction to “use judgment.”

5. Preserve the full chain of authority

A useful audit trail must record more than the final API call. It should preserve:

• the human or system that initiated the work;
• the Teammate that performed each step;
• the job and policy that applied;
• the credential scope issued at runtime;
• every delegation to another Teammate or tool;
• actions allowed, denied, escalated, and approved;
• the final outcome.

Logs are not only for incident response. They are the evidence that your operating model works. They let a manager review whether the Teammate stayed inside its role, whether access was broader than necessary, and whether the AI coworker’s real behavior still matches its job description.

Without this chain, accountability becomes guesswork. You know that something happened but not whether it was requested, permitted, delegated correctly, or reviewed at the right seam.

How to Audit AI Coworker Access This Week

You do not need to wait for a new standard or buy an enterprise control plane to improve the basics. Start with one production workflow and trace authority from beginning to end.

Step 1: Write the job in verbs and objects

Do not begin with a product or a model. Write what the Teammate does in precise terms: “read new support tickets, retrieve the matching customer record, draft a response, and request approval before sending.”

Avoid broad verbs such as “manage,” “handle,” or “own” until you break them into actions. Access policy cannot enforce a vague job description.

Step 2: List every identity in the path

Record the human requester, Teammate identity, service accounts, connectors, API clients, and downstream systems. Mark any point where the Teammate borrows a human session or shares a credential with another process.

Those shared identities are your first remediation targets because they erase attribution and usually carry excessive access.

Step 3: Compare required authority with available authority

For each step, write down what the job requires and what the credential actually permits. The difference is your blast radius.

If the Teammate needs to read one CRM pipeline but its token can export every customer, edit users, and delete records, the problem is not theoretical. The system has already granted those actions, even if the prompt says never to use them.

Step 4: Replace standing access with bounded access

Shorten credential lifetimes. Restrict accepted destinations. Separate read from write. Remove permissions that belong to the human manager rather than the Teammate.

Where task-scoped credentials are not available, put a narrow service between the Teammate and the destination. The service should expose only the specific actions the job requires. This can turn a broad vendor API into a small, enforceable interface.

Step 5: Add a seam before the highest-consequence action

Find the point where a mistake becomes expensive, public, irreversible, or hard to recover. Put explicit approval there. Make the proposed action legible enough that a person can review it quickly.

A human approval button attached to an opaque payload is not meaningful oversight. The reviewer needs the action, reason, affected records, expected outcome, and rollback path.

Step 6: Test a denied action

Do not stop after confirming that the happy path works. Ask the Teammate to attempt something outside its job: access a different account, send without approval, change a protected field, or reuse an expired credential.

The correct result is a structural denial with a useful record. If the only protection is that the Teammate politely refuses, the boundary still lives in behavior rather than infrastructure.

FAQ

Q: What is AI agent identity?
A: AI agent identity is a unique, verifiable identity assigned to an autonomous AI system, separate from the human who owns or invokes it. In business terms, each AI coworker should have its own account, lifecycle, permissions, and audit record rather than borrowing an employee’s identity.

Q: Is a separate identity enough to secure an AI coworker?
A: No. Separate identity improves attribution and lifecycle control, but the AI coworker still needs task-scoped authorization, short-lived credentials, infrastructure-enforced limits, approval seams, and a complete record of delegated actions.

Q: What is the difference between authentication and authorization for AI coworkers?
A: Authentication confirms which Teammate is making a request. Authorization decides whether that Teammate may perform this action on this resource under the current conditions. A request can be properly authenticated and still be unauthorized.

Q: Should an AI coworker ever use an employee’s account?
A: Not for production work. Borrowed accounts hide which actor performed the action and often grant the AI coworker every permission the employee has. Use a distinct identity with narrower, time-limited access instead.

Q: How should delegation between AI coworkers work?
A: Delegation should reduce or preserve authority, never expand it. Each handoff should carry the originating requester, the current actor, the permitted task, the allowed resources, and an expiration time. The receiving Teammate should not gain permissions the delegating Teammate did not have.

Q: What is the fastest practical security improvement for a small business?
A: Pick one workflow and compare what its credentials can do with what the job actually requires. Remove the excess, separate the Teammate from human accounts, and put human approval immediately before the most consequential action.

The industry is finally treating AI identity as infrastructure. The businesses that make it work will go one step further and make authority structural, specific, and provable. Associates AI Teammates gives you persistent AI coworkers with governed access, defined roles, and clear human seams on managed agent servers. View pricing and choose a plan.