Meta News

As organizations deploy autonomous AI agents across business systems, security teams are confronting a familiar problem in a new form:how much should a non-human identity be trusted?

AI agents can read corporate data, call APIs, execute code, communicate with other agents, and take actions across cloud applications. That makes them fundamentally different from conventional chatbots and turns identity and access management into a critical part of agent security.

The emerging answer follows the principles of Zero Trust: an AI agent should not receive broad access simply because it operates inside a trusted environment. Every identity, request, and action needs to be evaluated according to what the agent actually needs to accomplish. (⁠thehackernews.com)

Traditional identity systems were primarily designed around humans and relatively predictable machine identities such as service accounts.

Agents complicate that model.

A single AI agent might interact with Salesforce, Microsoft 365, GitHub, Slack, cloud infrastructure, internal databases, and custom APIs while completing one workflow.

Organizations may be tempted to provide broad credentials so the agent can operate without interruption.

That creates risk.

If the agent is compromised through prompt injection, manipulated by malicious data, or simply makes an incorrect decision, every permission assigned to it potentially becomes available for misuse.

An agent with excessive permissions therefore creates a problem similar to an overprivileged employee or service account — except that it can potentially perform actions at machine speed.

A core Zero Trust principle is that every agent should have its own identifiable identity rather than sharing credentials with users or other agents.

That allows organizations to determine exactly which system performed an action.

Shared API keys make this considerably harder. If dozens of agents use the same credential, security teams may know that an application accessed a database but not which agent initiated the request.

Unique identities also make revocation easier.

If one agent becomes compromised, defenders can disable that identity without disrupting every other workflow using the same credentials.

The same principle applies when agents delegate work to other agents. The identity chain should remain visible so organizations can determine who originally requested the action and which agents participated in executing it.

Long-lived credentials with broad privileges are particularly dangerous for autonomous systems.

Instead, agents can receive short-lived, task-specific authorization.

Imagine an AI agent responsible for processing an invoice.

It might need permission to read one document, retrieve information about one supplier, and create a payment request. It does not necessarily need permanent access to every invoice, customer record, and financial account.

Once the task finishes, those permissions can expire.

This approach limits the damage possible if the agent is manipulated while performing the workflow.

It also reflects the principle of least privilege: authorization should be based on the current task rather than everything the agent might theoretically need someday.

Identity controls become especially important because AI models cannot reliably distinguish trusted instructions from malicious content.

An agent might receive a legitimate instruction to summarize customer support tickets and encounter a ticket containing a hidden prompt telling it to retrieve confidential documents and send them somewhere else.

Preventing the model from following such instructions remains difficult.

But strong authorization can limit the consequences.

Even if the prompt injection succeeds at the model level, the agent should still encounter an independent security boundary when attempting an unauthorized action.

This is why authorization should exist outside the LLM rather than depending entirely on instructions such as “never reveal confidential information.”

The model can make a bad decision while the surrounding security architecture prevents that decision from becoming a successful attack.

Zero Trust for agents also requires more than simply checking whether a credential is valid.

Security systems need context.

An authorization layer could evaluate which agent is making the request, which user initiated the workflow, what task is being performed, which resource is being accessed, and whether the requested action makes sense within that task.

The same agent might therefore receive permission to access a customer record during one workflow but be denied access to it during another.

This represents a shift from static permissions toward dynamic, context-aware authorization.

For large organizations operating thousands of agents, this could become essential.

Agentic AI may dramatically increase the number of identities organizations need to manage.

One employee might eventually operate several specialized agents, while enterprise applications could create temporary subagents to perform individual tasks.

That means machine identities could quickly outnumber human identities.

Security teams will need inventories showing which agents exist, who owns them, which models they use, what tools they can access, and what permissions they possess.

Without that visibility, organizations risk creating a new version of the service-account problem at much greater scale: thousands of forgotten identities with credentials that remain valid long after their original purpose disappears.

AI security discussions often concentrate on model-level problems such as jailbreaks and prompt injection.

Those threats matter, but they cannot be solved entirely inside the model.

Organizations should assume that agents will sometimes misunderstand instructions, consume malicious information, or attempt inappropriate actions.

Security architecture therefore needs to control what happens next.

Unique agent identities, least-privilege permissions, short-lived credentials, contextual authorization, continuous monitoring, and complete audit trails provide layers of protection even when the AI itself makes a mistake.

That is ultimately why Zero Trust maps naturally onto agentic AI.

The objective is not to build an agent that can never make the wrong decision. It is to design an environment where one wrong decision does not automatically provide access to everything the agent can reach.