AI 智能體借用人類憑證行事，身份識別為何是首個問責缺口

Your AI agent has permission to act. Who has permission to take responsibility?

Picture the audit log after an incident. A record was changed, a permission was widened, a workflow ran. The log says alice. Alice was in a meeting and never touched the system. An agent, running on credentials it borrowed from her, did it. That is the first accountability gap: your records must say who, or what, acted.

The log says Alice. Alice didn't do it.

When an agent runs under a human's credentials, the record names only the human. Rig Security's CEO Guy Kozliner put it this way: "Today, the most active identities in an enterprise are AI agents, and they are acting under human names." (Biometric Update)

Rig Security's claim is that security teams cannot tell whether a person or an agent performed an action, and cannot stop the agent without blocking the person. Those two problems are real engineering problems whatever you think of the sales pitch: attribution and revocation both break when the agent and the human share one identity.

Here is what that looks like in a log. First, the record most systems write today:

{
  "time": "2026-10-20T09:14:02Z",
  "user": "alice",
  "action": "update",
  "resource": "customers/4412"
}

Nothing in it says an agent was involved. Now the same event with the agent as its own actor and Alice as the delegating human (an illustrative sketch, not a standard):

{
  "time": "2026-10-20T09:14:02Z",
  "agent": "support-triage-agent",
  "delegated_by": "alice",
  "action": "update",
  "resource": "customers/4412"
}

Same action, but now you can answer "was it Alice?" and "which agent?" separately, and you can disable one without touching the other.

What the numbers say (and how far to trust them)

In JumpCloud's Q4 2026 Pulse Report, as reported by BankInfoSecurity on 2026-10-09, 59% of agent-using respondents have not fully extended their human IAM policies to non-human users. The same survey found that 55% of organizations use or test agents that can change systems, permissions, records or workflows. (BankInfoSecurity)

Delinea's 2026 AI Policy Enforcement Report points the same way: 99.7% of organizations have a formal policy governing AI data access, but only about half check access against that policy in real time. It also found that 55% take a day or longer to detect an agent exceeding its scope, and 87% of IT leaders say an AI tool or agent accessed sensitive data beyond its intended scope in the past year.

A caveat: these are secondhand figures, and I have not seen the underlying reports. The BankInfoSecurity article does not state the JumpCloud survey's sample size, geography or fieldwork dates, and JumpCloud is a vendor of directory and IT management software. Treat the numbers as direction, not measurement: policies exist on paper, while enforcement and detection are slower than the agents.

Review after the fact, or approve before? The oversight split

The same JumpCloud survey asked how organizations handle high-risk agent actions. 46% of agent-using organizations let them run automatically and review logs afterward. 29% allow them with limited or no review. 18% require prior human approval.

Reviewing afterward is a legitimate design. But it only works if the log can attribute actions. If the record says alice for everything, the after-the-fact review is reviewing the wrong thing.

Approving before is not a free fix either. NIST researchers warned that excessive approval prompts can cause consent fatigue. If a human clicks "allow" all day, the prompt stops being a control. More prompts won't fix it. Better identity and better records will, because then few cases need a human and the rest can be audited honestly.

Give the agent its own identity

NIST researchers Bill Fisher and Ryan Galluzzo, as reported by BankInfoSecurity, say agents should be treated as first-class entities with unique identifiers, credentials and entitlements tied to the user or system operating them.

They also warned against shared human credentials, static API keys and long-lived bearer tokens, and pointed to OAuth 2.0 and SPIFFE for short-lived, tightly scoped credentials.

In practice, "its own identity" means the agent authenticates as itself and the credential it holds is narrow and expires quickly. Below is a sketch of a token request for such a credential. It is not a working flow: actor_sub is a name I made up, so use whatever claim your identity provider supports for delegation.

# sketch only: the issued token should expire within minutes, not days
POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=support-triage-agent
&scope=customers.read customers.update
&actor_sub=alice

What matters is the shape: the agent is the client, the scope is limited to what this job needs, the lifetime is short, and the delegating human is carried in the token so it can reach the audit log.

A note on sourcing: I could not read the NIST material directly for the two NIST points above, so they rest on BankInfoSecurity's reporting. Check the original before you build policy on them.

What an audit record must contain

Forrester analyst Andras Cser said agents should be managed within existing IAM frameworks, and that decisions should assess the human user, the agent and the resource acted on. That is a useful constraint: you do not need a parallel identity system, you need to extend the one you have so it can represent an agent next to the human.

On what to log, Cser named agent and runtime; the BankInfoSecurity article's list goes further: the delegating human, timestamps, actions, credentials, resource identifiers and reason codes.

This record extends the earlier sketch with the rest of that list (field names are mine, for illustration):

{
  "timestamp": "2026-10-20T09:14:02Z",
  "agent": "support-triage-agent",
  "runtime": "worker-pool-3",
  "delegating_human": "alice",
  "action": "update",
  "credential": "token:7f3a (expires 2026-10-20T09:29:02Z)",
  "resource": "customers/4412",
  "reason_code": "TICKET_ESCALATION"
}

Each field answers a question someone will ask after an incident: which agent, running where, for whom, doing what, with which credential, to which resource, and why.

Standards are still a proposal

NIST's NCCoE published a concept paper on software and AI agent identity and authorization on 2026-02-05. Public comments were due 2026-04-02 and the comment period is now closed. (NIST) The paper lists identification, authorization, and auditing and non-repudiation of AI agents among its topics for feedback.

Don't over-read it. The NCCoE said it is interested in launching a project to demonstrate how identity standards and best practices can be applied to software agents. That is a proposal for a demonstration project, not a finished standard, so you cannot point to it as a compliance requirement yet.

The market is moving too. Rig Security emerged from stealth with $12 million in seed funding, reported on 2026-09-30, and RSA launched RSA Agent ID, an agentic security identity platform aimed at regulated sectors such as government, financial services and critical infrastructure. Both come from a single outlet's reporting, so read them as vendor attention, not proof of maturity.

Fix attribution first

Argue about responsibility after you have fixed attribution, not before. A short checklist:

1. Give every agent its own identity. No borrowing a human's login, no shared credentials.
2. Use short-lived, scoped credentials. Avoid static API keys and long-lived bearer tokens.
3. Record the delegating human on every action, along with the agent, runtime, credential, resource and reason.

Cser's line is the one to keep in mind: "There needs to be somebody at the end of the story."

So, one question: when your agent changes something in production today, can your log say which agent did it and for whom?