Most AI Agents Run on Borrowed Logins: A New CISO Survey

AI agent identity means identifying the agent separately from the employee who assigned its task, then checking consequential actions against that task. In a Frontegg/Agen.co survey release, 40% of surveyed security leaders said they see agents operating on employee personal credentials; only 18% said their organizations verify an agent's identity before it acts. Those figures describe respondents' organizations, not the percentage of all agents that borrow logins.

Key Takeaways:

• A person's valid login doesn't establish which agent took an action or why.
• The 40% and 18% figures come from one vendor-sponsored survey of larger US employers, not an inventory of all deployed agents.
• A distinct identity, narrow access, an accountable human owner, and checks at sensitive actions make the audit trail useful.
• A service account can separate an agent from an employee, but an unowned, long-lived account still leaves major questions unanswered.

The CISO survey's headline numbers, and what they measure

The release says independent research firm Cint surveyed 300 CISOs and CSOs at US companies with at least 500 employees from September 24 to 27, 2026. It reports that 40% see agents using employees' personal credentials and 18% verify an agent's identity before it acts. Many check only at registration or session start. Read the full report landing page alongside the announcement.

The quoted percentages sit below the captured viewport. These self-reported observations cannot establish that most agents use borrowed logins, despite the assigned headline. Nor are the two percentages inverse measures.

Why agents inherit an employee login

A working assistant may inherit the account that opens your inbox and shared files. Suppose you ask an agent to organize a client handoff: it can use your session and reach the documents you can reach. A log under your name might record your click or an agent's unattended run.

A service account helps only with a clear owner and restricted scope. Microsoft's workload-identity overview distinguishes nonhuman applications and services from human identities. A static key shared between automations still won't identify the individual agent. Zentor MCP lets workspace memory reach different AI tools; review the permissions of each connection separately.

The risks when agent activity looks human

Misattribution is the first loss. A file-sharing event under an employee name doesn't reveal whether they clicked or an agent acted. A valid session can also carry permissions beyond the task. If you meant to sort invoices, the ability to modify unrelated customer records doesn't become appropriate because the login permits it.

The release also reports 53% use shared or long-lived keys; its incident comparison cannot establish causation. OWASP's LLM application security project documents risks such as excessive agency. A successful login doesn't make every subsequent action safe. Read the broader AI agent security framework for the surrounding controls.

What it means to verify agent identity before it acts

Verifying AI agent identity means checking the actor, owner, scope and action. Ask four questions at an action boundary: Which agent is this? Who owns it? What resource and operation does it request? Is that operation allowed under the current policy? Authentication answers the first question; authorization answers the last, after considering scope and context. A registration-time check alone won't answer whether this particular export or share is justified now.

This is a design goal, not a product claim. The NIST AI Risk Management Framework offers an organizational framework for managing AI risk; it isn't an agent identity protocol. Teams must still choose identity, logging and revocation mechanisms. For Zentor connections, record who grants access and how to review it.

Adoption is moving faster than governance

The survey reports that 84% of respondents observe more than a thousand agent actions weekly in production, while just 37% scope agent access to the task it was built for. Those figures describe larger US employers, not typical one-person businesses. A one-time login check can age badly.

If an assistant updates your orders, can you identify its changes and stop it without locking yourself out? The bring-your-own-agent governance guide covers the wider ownership problem. Portable memory isn't an identity credential.

A practical agent identity checklist for this quarter

An AI agent identity review starts with inventory, not another password.

1. List every agent and connection. Record the human owner, its job, the accounts it can touch, and who can shut it off. Start with tools that change or disclose data.
2. Separate identities where the tool allows it. Don't hand an agent an employee password merely to get a test working. Prefer an individually attributable, limited integration over a reused shared login.
3. Keep each grant narrow. Match read, write, share, and delete abilities to the specific task. Check sensitive operations again when they happen rather than relying on an approval from months ago.
4. Make the trail readable. Capture the agent, owner, requested action, resource, decision, and time. Test whether you can distinguish an agent action from your own.
5. Set an end condition. Remove or rotate access when the project or agent stops. Review permissions after a change in workflow, not only after an incident.

These prompts don't certify any product. Check permissions and audit settings yourself.

FAQ: AI agent identity and service accounts

What is agent identity?

It's a distinct, traceable way to identify a nonhuman actor when it accesses a resource, tied to an owner and policy. Knowing the agent's name is not enough; the system handling an action must be able to evaluate and record its permissions.

Why not just use a service account?

Use one where appropriate, but don't stop there. If several agents share it, or its secret lasts indefinitely and grants broad access, the account identifies a bucket rather than the agent and its current task. Individual attribution and action-specific authorization remain necessary.

What should a team without a security organization do?

Start with the agent that can do the most harm to your own files or customer records. Give it the smallest available permission, keep a named owner and a simple activity record, and rehearse revoking access. You don't need a large department to ask who did what.