Your AI Agent Should Not Borrow an Employee’s Login

POLICY POSITION

To: Operations owner Decision: Do not let an AI agent borrow an employee login. Control: Give the agent a distinct identity and a short-lived, task-specific authorization badge.

```text ALLOW only when agent + owner + purpose + resource + action + expiry + evidence are all present. Otherwise: DENY and route to a human. ```

Original AAHouse format-specific decision aid; conceptual, not a tested interface.

On October 27, NIST published ten proposed design tenets for agent identity management systems. They include distinct agent identification, attenuation of delegated rights, zero standing privilege, short-lived and revocable authorization, human-review triggers, separation of policy from reasoning, deterministic access decisions, continuous monitoring and immutable evidence. NIST notes that current standards and technology may not fulfill every tenet immediately; the post presents a direction for system design, not a certification of particular products. [1]

The design question is becoming practical as AI interfaces connect to more business applications. OpenAI and Oracle announced on October 27 that they intend to bring Oracle applications and data into ChatGPT through Oracle AI Workspace, with unified sign-in, organizational permissions and approved workflows. The companies describe a finance example spanning procurement, planning and month-end work. The offering and any reported usage or time savings are vendor announcements, not independently tested outcomes for small businesses. [2]

NIST’s February concept paper on software and AI-agent identity framed the underlying problem: agents may receive access to varied data, tools and applications, so identification, authorization, auditing, non-repudiation and prompt-injection controls require explicit design. The paper was an initial public draft seeking input, not final implementation guidance. [3]

CONTROL — Separate identity from authority

Identity answers: Which agent is this?

Authority answers: What may this agent do right now?

Keeping those questions separate is essential. An agent can have a stable identity for accountability without holding permanent access. When work begins, a policy system—not the model’s own reasoning—can issue a temporary grant based on the task, requester, environment and risk.

A small-business implementation does not need to invent a new cryptographic standard. It does need to refuse three shortcuts:

• sharing an employee password or browser session with the agent;
• storing a broad, reusable token in a prompt, script or configuration file; and
• assuming that because the agent can read a record, it may also modify, send, approve or delete it.

BADGE SPECIFICATION — Seven fields

For each meaningful task, record an authorization envelope with:

• Agent identity and version. Which exact configured agent is running?
• Initiator. Which person, process or approved schedule requested the task?
• Purpose. What business outcome is authorized?
• Resources. Which customer, order, folder or application records are in scope?
• Actions. Is the agent allowed to read, draft, update, send, approve or delete?
• Time and stop conditions. When does the grant expire, and which event revokes it early?
• Evidence destination. Where will the independent action receipt be written?

This seven-field badge is an original AAHouse operating recommendation. It translates identity principles into a reviewable task record; it is not a feature promised by the cited organizations.

DECISION EXAMPLE — Refund assistant

Imagine a small online retailer wants an agent to help with low-value refund requests.

The employee-login shortcut would give the agent the service representative’s entire session: customer profiles, order history, address changes, notes, refund controls and perhaps other administrative functions.

The badge approach is narrower. For one customer request, the policy system grants the identified agent ten minutes to:

• read one order and its shipment status;
• compare the request with a fixed refund policy;
• prepare a refund recommendation; and
• draft, but not send, the customer response.

It cannot change the delivery address, view unrelated customers, modify the policy, approve a refund or keep access after the task ends. If the order value exceeds the threshold, the shipment state changes or the customer message contains conflicting instructions, the grant ends and a human receives the evidence.

This example is hypothetical. The ten-minute window and task boundaries are illustrative, not a universal control or a reported result.

DELEGATION RULE

An agent may call another service or sub-agent. That handoff should never increase its authority.

If the parent task can read one order and draft one response, a downstream inventory lookup should receive only the product identifiers required for that lookup. It should not inherit customer contact data or refund controls. A writing component may receive approved facts for the draft, but not the credential that can change the order.

This creates a chain in which every downstream grant is equal to or narrower than the parent grant. A broad employee session creates the opposite pattern: every connected component may inherit more access than its task needs.

ENFORCEMENT — Keep the gate outside the model

The agent can propose an action, explain its reason and supply evidence. A deterministic policy layer should decide whether the requested action fits the badge.

For example:

• “read order 482” can be evaluated against an allowed record identifier;
• “draft response” can be distinguished from “send response”;
• “refund $38” can be blocked because the badge permits recommendations only; and
• a request after expiration can be denied even if the agent says the task is almost complete.

Natural-language guardrails remain useful, but the same reasoning system that reads untrusted customer messages should not be able to rewrite its own permissions.

CLOSEOUT — Expire and preserve evidence

At task completion, the temporary authorization should disappear. It should also be revocable during the run if the initiator withdraws the request, the context changes, a risk signal appears or the agent departs from scope.

Write the evidence somewhere the agent cannot alter. The receipt should connect the agent identity, initiating request, grant, attempted actions, completed actions, blocked steps, human decisions and final revocation. Avoid copying unnecessary customer content into the log; stable record references and outcome categories may be enough.

Useful pilot measures include the percentage of tasks using distinct identities, the percentage ending with zero remaining privilege, blocked out-of-scope attempts, revocation time, missing receipts and human escalations that reviewers routinely approve without examination. These are proposed measures, not published results.

An employee’s login represents a person’s ongoing job. An agent badge should represent one bounded delegation. That difference makes connected AI easier to stop, explain and trust.

Original AAHouse analysis, prepared October 28, 2026. AI-assisted writing and original conceptual illustration; approved format-diverse edition. Examples are hypothetical. No hands-on product testing or full video viewing was performed.