Give the agent its own identity before it touches the ledger.

Borrowed credentials are not an agent strategy

Someone ships an agent that can open a purchase order, move inventory, or pull a customer record. The demo works. The credential behind it is a developer's Entra account, a shared service password in a vault nobody rotates, or a long-lived API key copied into three environments. When something writes the wrong line, the audit says a human did it—or says nothing useful at all.

That pattern is breaking in public. IBM watsonx Orchestrate put Agent Identity into preview—agents get a distinct identity in the IdP you already run (IBM Verify or Microsoft Entra), with scoped tokens and an audit trail that can name the user, the agent, and the tool. Other control planes are pushing the same idea: treat the agent as a principal, not as cosplay on a person's badge. The product names are a hook. The operating decision is older and sharper.

If the agent can change money, stock, PII, or ERP state, it needs its own identity in your identity provider before you widen write access. Not "later, after the pilot." Not "under the platform team's break-glass user." Its own subject, its own scopes, its own disable switch.

This note is a direct argument for that gate, then a TWIMCO Agent Identity Provisioning Card you fill so the gate is concrete. No invented adoption rates. No pretend client KPIs. Just the questions security, platform, and the business owner should answer on one page before the agent touches the ledger.

When that work is how you are building agents into real systems, start from AI applications & agents.

What the card forces you to name

Fill one TWIMCO Agent Identity Provisioning Card per agent job that can write—or that will write soon. Reading a public FAQ is not the same risk. Writing a PO is.

Agent id. Stable name the runtime and the IdP both know: ops.po-draft.v2, finance.recon.nightly. If the name only lives in a Slack channel, you cannot disable it cleanly.

IdP subject. The non-human identity object in Entra, Okta, IBM Verify, or whatever you run—app registration, workload identity, or the agent identity type your IdP now supports. Write the object id or unique name. "Uses the shared automation user" is a failed card.

Owner. The role who may change scopes, rotate secrets, and approve disable. A shared inbox is not an owner. Two owners with no on-call rule means nobody answers at 2 a.m.

Allowed systems and actions. Named sinks: which ERP modules, which inventory writes, which PII fields. Prefer action verbs over "full access to SAP." If you cannot list the writes, you are not ready to provision them.

Scopes and token shape. Short-lived where the IdP allows it. On-behalf-of versus agent-as-itself—write which model you are using and why. Standing user impersonation without an agent identity is the anti-pattern this card exists to kill.

Human gate. Which writes still require a named person after the agent proposes. Identity does not replace judgment; it makes the judgment attributable.

Disable path. Who can turn the IdP identity off, how fast it stops the agent, and what breaks when it does. If disable only works by revoking a developer's password, you never provisioned an agent—you borrowed a person.

Audit join keys. How you join user → agent → tool → downstream record. Without join keys, "we have logs" is theater.

Secrets posture. No static keys in prompts, notebooks, or CI for production writes. Prefer IdP-issued tokens or vault-brokered short-lived credentials bound to the agent subject.

That field set is the unreproducible asset. Another vendor can announce agent identity. They do not have your agent ids, your sinks, your disable path, or your join keys.

Provision before write—not after the incident

Treat identity like a hard gate on write access, the same way you treat network allowlists for production databases.

Read-only pilots can limp on weaker credentials if you accept the risk and label it. The moment the agent may create, update, delete, or approve, the card must be filled and the IdP object live. "We will wire Entra next sprint" is how you get an incident with a human's name on a machine action.

Separate three things people conflate:

Builder identity. The engineer who deploys the agent. They should not be the production principal for overnight runs.

Invoker identity. The person who asked the agent to act. Keep that in the audit trail. Do not collapse it into the agent's write credential.

Agent identity. The principal that holds scopes for tools. Disable this and the agent stops, regardless of who is chatting with it.

IBM's preview language lands here for a reason: identity separate from the builder and the user, connected to the IdP you already trust, with short-lived scoped access and an audit link across the chain. You do not need that exact product to apply the gate. You need the discipline in your IdP and in your agent runtime.

If your control plane already sells agent identities, use it—and still fill the card. A product toggle is not a filled owner, sink list, or disable drill.

How teams fake agent identity

Composites—not measured breach rates, not a client scorecard.

The shared automation user. One mailbox-shaped account for every bot. Convenient until you cannot revoke one agent without killing twelve.

The developer's badge. Local runs and production runs share a human token. The audit lies forever.

The immortal API key. Minted for a demo, pasted into the agent config, never rotated, never bound to a subject your IdP can disable.

The silent OBO. The agent acts "as the user" with the user's full graph of permissions because that was the fastest OAuth sample. Scoped agent identity was skipped.

The disable that isn't. Turning the agent off in the orchestrator while the credential still works from a cron job or a forgotten worker.

When you see these, do not add another prompt rule about "being careful with PII." Fill the Agent Identity Provisioning Card. Create or map the IdP subject. Bind scopes to the sinks you named. Drill the disable path once before go-live. The card is what competitors cannot reproduce by prompting a model—your subjects, your sinks, your owners, your join keys.

Put this into practice

1. List every agent (or planned agent) that can write to money, inventory, PII, or ERP—or that will within a quarter.
2. Fill a TWIMCO Agent Identity Provisioning Card for each: agent id, IdP subject, owner, sinks and actions, scopes and token shape, human gates, disable path, audit join keys, secrets posture.
3. Refuse production write access until the IdP subject exists and the disable drill has been run once.
4. Replace shared human logins and static keys for those writes. Keep builder and invoker identities in the trail; do not use them as the write principal.
5. If the gap is designing agents that operate inside real business systems with permissions you can defend—not another demo—bring the cards into a scoping conversation for AI applications & agents. Business automation work that wires the same systems sits next door at business automation.

An agent without its own identity can still look smart in a screenshot. It cannot be governed when it touches the ledger.

Related work: Sutton|Place.