Agentic AI Is Breaking Security’s Human Trust Assumptions

Agentic AI reached Google News with a stark conflict: autonomous systems can now act faster than the human-centered controls designed to contain them.

A recent Forbes analysis argues that security programs still assume people initiate important actions and remain accountable for them. AI agents undermine both assumptions. They can select tools, retrieve data, call APIs, and complete multistep tasks with limited human involvement.

The article reflects a broader security debate, not one isolated breach or product announcement. Microsoft, Google Cloud, and security standards groups are developing controls for agents as distinct digital actors. Their work challenges an older model built around human users, predictable applications, and relatively stable permissions.

That tension matters because an agent does not need malicious intent to cause damage. A compromised instruction, excessive permission, poisoned memory, or mistaken plan can produce a harmful sequence of legitimate actions.

The central contest is therefore autonomy versus human-centered control. Businesses want agents that can finish work without constant approval. Security teams need evidence that every identity, permission, tool call, and consequential action remains constrained.

The solution is not simply placing another person beside every workflow. That approach removes much of the speed businesses expect from autonomous systems. Security must instead move closer to the agent’s execution path, where software can enforce limits before an action occurs.

Why Agentic AI Security Reached Google News

The news is not that AI can make mistakes. The change is that those mistakes can now reach real systems and trigger real actions.

Traditional generative AI usually waits for a person to submit a prompt. It returns text, an image, or code for someone to review. That interaction creates an obvious checkpoint between model output and operational impact.

Agentic AI removes or narrows that checkpoint. An AI agent is a system that pursues a goal through planning, tool use, and repeated actions. It can gather information, choose a route, and adjust after a failed step.

That ability changes the risk calculation. A chatbot can recommend deleting a production database. An overprivileged agent can attempt the deletion, retry after an error, and search for another credential.

The same distinction applies to ordinary office work. An assistant that drafts an email creates a reviewable artifact. An agent that finds recipients, attaches internal documents, and sends the message can expose information before anyone notices.

A Forbes security argument describes agents crossing environments, identities, and data boundaries that security teams usually manage separately. The author, Cyera executive Jason Clark, presents this as a structural problem for existing controls.

That source is a Forbes Technology Council contribution, not an independent investigative report. Its claims should be read as an industry executive’s analysis. However, its core concern appears across independent research, vendor guidance, and emerging technical standards.

The important change is delegated authority. An agent may operate through a user’s identity, a service account, or its own credential. Each model creates difficult questions about responsibility and permission scope.

Borrowing a user’s account gives the agent every entitlement assigned to that person. Shared service accounts make attribution difficult. A separate agent identity improves visibility, but only if systems can evaluate its context continuously.

Agents also create longer chains of causation. One agent may ask another agent to search records. The second may call a third-party tool, which retrieves data and passes it into another model.

Every handoff creates another trust decision. Security teams must determine who initiated the task, which agent acted, what authority it received, and whether that authority remained valid.

Google News exposure gives this issue broader visibility, but aggregation is not the event itself. The actual event is the convergence of deployment and security evidence. Agents are moving into workflows while identity controls remain oriented around humans and static workloads.

That gap turns an architecture discussion into an operational one. Security leaders now need to govern actions produced by systems that interpret goals instead of following one fixed sequence.

Security Still Assumes a Human Is Behind the Keyboard

Most access systems answer whether an identity has permission, but agents force them to ask whether this action still fits the delegated purpose.

Human-centered security rests on several practical assumptions. A person signs in, understands organizational rules, and performs actions at a roughly human pace. Investigators can question that person when activity looks unusual.

None of those assumptions transfers cleanly to an agent. An agent can make thousands of decisions without fatigue. It can also interpret an ambiguous instruction differently across two otherwise similar sessions.

Traditional identity and access management, commonly called IAM, controls who can access systems and what that identity can do. Roles often grant a stable collection of permissions based on a job or technical function.

An employee in finance might receive access to invoices, payment tools, and reporting systems. A service account might receive database access for one application. Reviews then confirm that those permissions remain appropriate.

An agent can cross those boundaries within a single assignment. A request to resolve a supplier problem might require email, contracts, invoices, payment status, and internal messaging. Static roles struggle to express the exact authority needed for that temporary objective.

The Cloud Security Alliance reported a significant visibility gap in a 2026 enterprise survey. Although 73% of organizations expected agents to become vital within a year, 68% could not clearly distinguish agent activity from human activity. The findings appear in its autonomous agent survey.

That distinction is essential for investigation. If an agent uses an employee’s token, a conventional log might show only the employee identity. Analysts may not know whether the person clicked a button or delegated the action to software.

The human assumption also shapes approval design. Many controls treat authentication as the main trust event. Once a user passes that gate, systems allow authorized activity until a session ends or another policy intervenes.

Agents require more frequent decisions. Permission should depend on the task, current step, requested resource, tool, data sensitivity, and consequences of the proposed action.

Consider a research agent asked to assemble a quarterly market briefing. Reading approved public sources fits that purpose. Opening confidential acquisition files does not, even when the requesting executive can access them.

The agent’s borrowed identity may authorize both actions. A purpose-aware control must still reject the second one because it falls outside the assigned task.

Speed compounds this weakness. A person who encounters repeated access failures may stop and contact support. An agent may retry, choose another tool, or search its available context for a different credential.

Those behaviors can resemble an attack even when the agent follows its goal. They can also amplify an actual compromise because automation removes the delays that normally give defenders time to react.

Security teams are therefore pressured to separate three identities: the human delegator, the executing agent, and the service or tool receiving the request. Losing any part of that chain weakens attribution.

The required response is not a larger employee directory. It is an authorization model that preserves delegation context across every step and expires access when the task ends.

Autonomy and Control Pull in Opposite Directions

The features that make agents valuable also make permanent trust dangerous: independence, persistence, broad tool access, and adaptive planning.

A useful agent must have enough freedom to choose actions. If every minor step requires human approval, the agent becomes an elaborate interface for manual work.

Yet unrestricted autonomy creates an unacceptable security model. A model can misunderstand a goal, follow malicious content, select the wrong record, or disclose information through an approved tool.

Prompt injection illustrates the conflict. This attack places instructions inside content that a model reads, hoping the model will treat that content as commands. A web page, document, email, or tool response can carry the hostile text.

A conventional application separates executable instructions from ordinary data through code and system boundaries. Language models process both through the same reasoning context, making that distinction harder to enforce consistently.

An agent browsing the web might encounter a hidden instruction telling it to reveal stored information. If the agent has access to sensitive memory and a communication tool, one poisoned page can connect those capabilities.

The failure spans several control layers. The model misclassifies data as an instruction. The application permits an unnecessary data read. The tool accepts an outbound action without verifying its purpose.

Blocking one suspicious phrase cannot solve that chain. Attackers can rewrite instructions, split them across content, or exploit indirect references. Defenders need controls outside the model’s own reasoning process.

Microsoft’s agent security guidance recommends unique digital identities, least-privilege access, guardrails, approval workflows, and auditing. These controls reduce dependence on the model obeying a written instruction.

Least privilege means granting only the access required for a specific task. For agents, that principle must become narrower and more temporary than many existing enterprise roles.

An expense agent may need to read one submitted receipt and one policy document. It does not need permanent access to every employee’s expenses. It also should not approve its own exception.

Short-lived credentials can limit exposure. A broker can issue a credential for one agent, task, resource, and time window. The receiving service can verify those conditions before accepting an action.

High-impact steps need stronger barriers. Sending money, deleting records, changing production systems, or exposing regulated data should trigger deterministic policy checks. Deterministic means the same defined conditions produce the same decision.

The model can propose an action, but it should not decide whether its own action is permitted. That separation mirrors familiar security practice, where applications request access and policy systems evaluate the request.

Human approval still has a role, particularly when intent cannot be expressed safely in code. However, approval prompts must provide meaningful context. A generic “allow” button transfers risk without improving judgment.

A reviewer should see the requesting human, executing agent, affected resource, proposed action, expected result, and reason for escalation. The approval should cover only that action, not every later step.

This design preserves useful autonomy inside defined boundaries. Agents can handle low-risk retrieval and analysis without interruption. Consequential actions encounter progressively stronger checks.

The tradeoff never disappears. Tighter boundaries reduce flexibility, while broader authority increases the possible impact of mistakes. Enterprises must decide where autonomy creates enough value to justify that residual risk.

Identity Is Necessary, but It Cannot Explain Intent

Giving every agent a name improves accountability, but identity alone cannot determine whether a valid action belongs inside the current task.

Identity has become the most common starting point for agentic AI security. That makes sense. Defenders cannot govern or investigate an actor they cannot distinguish from users and background services.

Google Cloud said in May 2026 that traditional controls were not designed for autonomous agents interacting with sensitive data at machine speed. Its agent identity controls focus on managing agent access and strengthening runtime defenses.

Microsoft similarly treats an agent as a digital actor that should receive a separate identity. This allows policies and logs to distinguish an agent’s actions from those of the person who assigned its task.

The Coalition for Secure AI goes further in its agentic IAM framework. It examines how existing identity protocols must represent agents, delegated authority, and access decisions.

These efforts pressure established IAM vendors, cloud platforms, and application developers. Every layer must carry enough context for downstream systems to make informed authorization decisions.

A unique identity can answer which agent made a request. It cannot automatically answer why the request exists, whether the plan changed, or whether the resource remains necessary.

That limitation matters because a compromised agent can authenticate correctly. Stolen credentials, poisoned instructions, altered memory, or a manipulated tool response do not always produce an invalid identity.

The agent may perform individually permitted actions that form a harmful sequence. Reading customer records, compressing selected files, and sending an outbound message can each look normal when evaluated separately.

Together, those actions can represent data theft. Security systems need to examine the trajectory, meaning the ordered path of decisions and actions across the task.

A 2026 research paper on trajectory assurance argues that per-action checks are insufficient for agent systems. The authors emphasize architectural verification across identities, delegation, communications, and execution controls.

This approach resembles behavioral detection, but it adds task context. An agent assigned to summarize contracts should not begin changing access policies, even if its technical permissions allow that action.

Runtime controls can compare the current action with the original goal, approved plan, previous steps, and remaining authority. They can pause execution when the trajectory drifts outside expected boundaries.

Logging also needs greater precision. A useful audit trail should record the delegator, agent identity, model version, tool call, accessed resource, policy decision, and resulting side effect.

However, organizations should be cautious about logging private reasoning or sensitive prompts without limits. Detailed records can themselves contain confidential data, credentials, employee information, or customer content.

Auditability therefore creates its own security and privacy obligations. Logs require access controls, retention rules, tamper resistance, and a defined purpose. More telemetry is not automatically safer telemetry.

Memory introduces another complication. An agent may retain preferences, task history, or operational context across sessions. Corrupted memory can affect later actions long after the original malicious content disappears.

Organizations need provenance for those memories. Provenance records where information originated, how it changed, and which process approved its continued use.

Sensitive knowledge workflows also benefit from keeping source material organized and traceable. A searchable knowledge base can support human review, but it does not replace agent authorization.

Identity is therefore one control plane, not the complete answer. Secure execution also requires purpose limits, external policy enforcement, trajectory monitoring, and recoverable records.

The Hardest Problem Is Accountability After Delegation

An agent can execute a decision without becoming legally, operationally, or ethically responsible for its consequences.

Human-centered security assumes accountability eventually leads back to a person or organization. Agentic systems complicate that path without removing it.

A business leader may authorize an agent for a broad outcome. A developer may select its tools. A platform team may manage credentials. A security team may define policy, while a vendor supplies the underlying model.

When the agent causes harm, each participant can point to another layer. The leader did not choose the exact action. The developer did not create the malicious content. The model provider did not grant production access.

That fragmentation creates an ownership gap. Technical attribution can identify which component acted, but organizational accountability must identify who accepted the risk and who can stop the system.

Every production agent needs an accountable owner. That owner should approve the agent’s purpose, data boundaries, tools, risk classification, and escalation path.

Ownership should not mean reviewing every output. It means maintaining the conditions under which autonomy remains acceptable. It also means suspending the agent when evidence falls outside those conditions.

Security teams need a current inventory of agents and their capabilities. Each record should include the agent’s owner, delegators, credentials, connected tools, data access, model dependencies, and permitted consequences.

The inventory must reflect real deployments, not only approved projects. Agents can enter through software features, employee-built automations, development frameworks, browser extensions, and third-party integrations.

Discovery is difficult because an agent may resemble ordinary API traffic. It might use an existing user token or service account. Without agent-specific signals, defenders see the action but miss the actor.

Accountability also depends on reversibility. Systems should define which actions can be undone and how quickly. Sending a draft to a review queue is reversible. Publishing it publicly creates a wider and less predictable impact.

The same distinction applies to security operations. An agent can recommend isolating a device. Automatically disconnecting a hospital workstation or production server carries a different operational risk.

Organizations should classify actions by consequence. Read-only access, internal drafting, external communication, financial transactions, permission changes, and destructive operations should not share one approval policy.

The skeptical view deserves attention here. Some proposed agent controls remain vendor claims, architectural recommendations, or early standards. Their effectiveness across heterogeneous production environments has not been established at broad scale.

Unique identities do not prevent poor decisions. Detailed logs do not stop an action already completed. Human approvals can become routine, rushed, or vulnerable to misleading context.

Even an external policy engine can contain errors. A rule may omit an unusual workflow or permit a harmful combination of individually acceptable actions.

Security programs should therefore avoid claiming that agent identity “solves” autonomous risk. It improves visibility and enforcement, but residual uncertainty remains inside models, tools, data, and organizational decisions.

The safer objective is bounded failure. An agent should have limited access, limited time, limited spending authority, and limited ability to affect other systems.

When failure occurs, teams should be able to reconstruct the sequence, contain the agent, revoke its credentials, restore affected resources, and update policy.

That model treats mistakes as expected operational events. It is more realistic than assuming every prompt, model response, and tool call will behave as intended.

Three Signals Will Show Whether Security Is Catching Up

The next phase will be measured by enforceable controls and production evidence, not by additional warnings about autonomous risk.

The first signal is adoption of task-scoped agent identities. Cloud platforms and enterprise applications must show that an agent can receive temporary authority without inheriting a user’s complete access.

Watch for credentials bound to a specific delegator, purpose, tool set, resource, and expiration time. Also watch whether downstream applications can evaluate that context instead of accepting a generic bearer token.

Widespread support would strengthen the case that existing identity infrastructure can evolve for agents. Slow adoption would expose a difficult interoperability problem, especially across multiple clouds and software vendors.

The second signal is independent testing of runtime controls. Vendors increasingly describe guardrails, monitoring, and agent-specific authorization. Buyers need evidence that these systems stop realistic multistep attacks and accidental policy violations.

Tests should include indirect prompt injection, poisoned memory, compromised tools, privilege escalation, and harmful combinations of permitted actions. They should also measure false positives that interrupt legitimate work.

Strong results across different models and applications would support the move toward runtime enforcement. Results limited to controlled demonstrations would weaken claims that the architecture is ready for broad deployment.

The third signal is whether organizations can reconstruct agent actions after an incident. Regulators, insurers, customers, and internal auditors will ask who delegated authority and why a consequential action passed policy.

A complete record should connect the human request to the agent, model, tools, data, approvals, and final side effect. Missing links will reveal that accountability still depends on inference.

This signal also tests operational readiness. A company may have detailed logs but no owner authorized to suspend the agent. Another may revoke credentials but lack a clean recovery point.

Readers following agentic AI through Google News should separate three different stories. Model capability describes what agents can attempt. Product adoption describes where businesses deploy them. Security maturity describes whether those deployments remain governable.

Those curves are not moving at the same speed. Agent capabilities and integrations can expand through software updates. Identity redesign, application support, audit practices, and organizational ownership require coordinated changes.

Developers should ask what authority an agent truly needs before connecting another tool. Enterprise buyers should demand evidence about identity separation, policy enforcement, logging, and incident containment.

Knowledge workers should notice when an assistant begins taking actions instead of proposing them. That boundary determines whether an error remains a draft or becomes an operational event.

The most useful question is not whether an agent behaves like a person. It is whether the system can constrain an actor that operates differently from any person.

Human oversight remains important, but it cannot remain the only safety mechanism. People cannot review every machine-speed decision without eliminating the autonomy businesses purchased.

Security must encode human intent into enforceable technical boundaries. It must preserve that intent through delegation, tool calls, memory, and changing plans.

The Google News attention cycle will move to another headline. The underlying test will remain: can organizations grant useful autonomy without granting invisible, persistent, and unaccountable authority?

Before deploying the next agent, map one complete task from instruction to consequence. Identify every credential, data source, tool, approval, and recovery step. Any missing link is not merely a documentation gap. It is a place where autonomous action can outrun human control.