Your AI Agent Logs In As You. Would Anyone Know What It Did Last Week?

Most of the artificial intelligence (AI) automation running inside businesses today signs in as a person. The agent that chases unpaid invoices uses the bookkeeper's login. The one that sorts the inbox holds a key generated from a marketing manager's account. The reporting agent was given the owner's password, because that was the account with access to everything. All of it works on the first day, and all of it quietly removes the business's ability to answer a question that arrives later: of everything that happened last week, which actions were taken by a human being and which were taken by software acting in that person's name. The system log holds one answer, and it is the person's name.

The question stopped being academic this year, because the work handed to agents stopped being small. Anthropic's 2026 State of AI Agents Report, produced with the research firm Material from a survey of more than 500 technical leaders taken in late 2025, found 57% of organizations already running agents on multi-stage workflows and 16% pushing them into cross-functional processes that span several teams ¹. Eight in ten say those investments are already delivering measurable economic returns rather than pilot results ¹. The usage data is blunter than the survey. Anthropic reports that 77% of business traffic through its application programming interface (API) shows automation patterns, meaning companies handing off complete tasks rather than using AI as a collaborative assistant, and that over eight months the share of conversations delegating a whole task rose from 27% to 39%, the first time automation overtook assistance ¹. The report notes plainly that these workflows tend to involve sensitive customer data, proprietary business logic and access to internal systems ¹. On 10 September 2026 OpenAI put its Agents API into public beta, with managed sessions that survive across turns and handle orchestration, context and recovery for the developer ². That is infrastructure for agents that keep working when nobody is watching the screen.

The way nearly all of those agents are connected is the part standards bodies have now called wrong. A draft specification filed at the Internet Engineering Task Force (IETF) in March 2026, by authors from Defakto Security, Amazon Web Services, Zscaler and Ping Identity, states that static API keys are an antipattern for agent identity: they are bearer artifacts that are not cryptographically bound, they do not convey identity, they are typically long-lived, and they are difficult to rotate ³. The same draft sets out what should replace them. Where an agent acts on behalf of a person or a system, that authority has to be delegated to it deliberately, and the context of who authorized the action has to be recorded in the audit trail ³. Neither half describes how business automation is usually wired. Independent measurement points the same way: a paper published in March 2026 proposing an identity protocol for agents observed that agents call tools through the Model Context Protocol (MCP) and hand work to other agents through Agent-to-Agent (A2A), yet neither protocol verifies agent identity, and reported that a scan of approximately 2,000 MCP servers found all of them lacking authentication ⁴.

This is a commercial risk rather than a documentation problem because of what an agent's permissions become once the agent is fooled. The Open Worldwide Application Security Project (OWASP) published its Top 10 for Agentic Applications on 9 December 2025, and three of the ten entries describe one failure from different angles: identity and privilege abuse, where leaked credentials let agents operate far beyond their intended scope; tool misuse, where agents bend legitimate tools into destructive outputs; and human-agent trust exploitation, where confident, polished explanations mislead operators into approving harmful actions ⁵. The United Kingdom's National Cyber Security Centre (NCSC) explained in December 2025 why this cannot be patched away like an older class of bug. Inside a large language model there is no distinction between data and instructions, only the next token, so there is a good chance prompt injection will never be properly mitigated the way the classic database-injection attack it gets compared to eventually was ⁶. Its practical rule is the one a business can act on directly: when a model processes content from an outside party, its privileges effectively drop to that party's, so a model reading messages from strangers should not also hold privileged tools ⁶. An inbox agent that can read and also send, on a staff login, is one hostile email away from acting for someone who does not work at the company.

The alternative now exists, which removes the defence that there was nothing better available. Google Cloud issues what it calls an Agent Identity, a cryptographic identity attested for each individual agent that, unlike the shared service accounts businesses have leaned on for years, is not shared between workloads by default, cannot be impersonated, and does not allow long-lived keys to be generated from it ⁷. The sentence that matters for accountability sits in the same documentation: when an agent acts on a user's behalf, the logs show both the agent's identity and the user's ⁷. The tool standard moved in the same direction. The MCP authorization specification requires an access token to be issued for one specific server as its intended audience, requires that server to validate the token was meant for it, forbids servers from accepting or passing on any other token, and tells clients to request only the permissions the immediate operation needs ⁸. Out of the jargon, the principle is ordinary: an agent should hold a key cut for one door and one job, not the master key a member of staff carries.

There is a second half to the same question, pointing the other way. Agents now arrive at a business's own website acting for customers, and the web's plumbing has begun separating the software's identity from the authority behind it. Cloudflare's bot classification, updated in July 2026, carries a category for agentic services where, in its own wording, the operator runs the software but each action is initiated by a different end user ⁹. The method behind it, which Cloudflare calls Web Bot Auth, uses cryptographic signatures carried inside the request itself to verify that the request came from an automated bot ¹⁰. For a business that turns a vague unease into a decision with two directions: which agents may act on its site and what they may do there, which is the readiness question covered in AI agents now operating your website, and separately, what the business's own agents are permitted to do elsewhere under its name.

Answering that does not require a business to become a security company. It requires four answers, and any competent build should be able to produce them. Which automations are currently running, and whose login each one uses. What each can reach, which should be the narrowest set of systems that completes its job rather than everything the borrowed account happened to have. What it may not do without a person, which is where irreversible actions belong: sending on behalf of the company, spending money, publishing, deleting, changing a price. And whether a log exists that names the agent, the person or system that authorized it and the time, in a form somebody outside the team could still read six months later. A business that cannot answer the fourth one does not know what its automation did, and will not learn it from the agent, which keeps no account of its own.

Inside most businesses nobody owns this. The automation was built by whoever had the idea and the password at the same time, usually in marketing or operations rather than in a technical team, and it was judged on whether it worked, because it did. The credential outlives the project and frequently the employee. The permissions are never narrowed afterwards, because narrowing them risks breaking something that is running fine. Nothing forces a reckoning until the first action that has to be explained to a customer, an auditor or a bank, and at that moment the only honest answer available is that the record says a member of staff did it.

So, plainly: should a business let an AI agent use a staff login or a long-lived key? No. Each agent should have an identity of its own, the narrowest access that completes its task, credentials that expire, and a person standing in front of anything that cannot be undone. For the ambiguous cases in between, one question settles it. If this action turned out to be wrong, could the same agent reverse it without a human being? If yes, let it run unattended. If no, it needs its own identity and a named human authorization before it fires, and the log has to hold both.

Italian DesAIgns builds AI automation as human-in-the-loop systems for that reason: access reaching the business's systems through secure relays and strict access tokens rather than a borrowed staff login, a person reviewing the steps that cannot be taken back, and operational logging on every workflow so there is a record to read afterwards. The protocol groundwork underneath it is covered in how MCP and A2A made AI agents plug-and-play, the failure modes that appear once automations multiply in why AI automation breaks at scale, and the payment side of agents acting for customers in AI agents completing checkout directly. The insights archive tracks the identity standards as they firm up. For the public-facing half, the free AI visibility check scores one page out of 100 on metadata and OpenGraph tags, heading structure, structured data and crawler access, and returns up to three prioritized fixes. It reads a page the way a crawler receives it, and it does not inspect a business's automations, credentials or permissions. That half starts with a conversation rather than a scan.