Welcome to this week’s edition.

AI agents can now read emails, modify repositories, trigger CI/CD pipelines, access databases, send Slack messages, query internal APIs, write files, call tools and even coordinate with other agents.

Problem is that most of them still authenticate like normal software:

→ Static API keys.

→ Inherited OAuth scopes.

→ Cloud credentials.

→ Kubernetes secrets.

Broad permissions that were never designed for non-deterministic systems.

That missing security layer is becoming one of the biggest hidden risks in modern AI infrastructure.

In March 2026, the draft for the Agent Identity Protocol, also called AIP, introduced a new approach to securing AI agents through verifiable identity, policy enforcement and tool-level authorization.

Instead of treating agents like ordinary software processes, AIP treats them as independent actors with their own identity, permissions, accountability and audit trail. (Currently implementing this for a Client also)

The core idea is simple:

An AI agent should never operate with unrestricted “God Mode” permissions just because it inherited a user token.

Let’s get into it ~

Most AI agents today execute actions using credentials that belong to a user, service account or application.

That usually means:

From the perspective of downstream systems, the action often looks like it came directly from the human user.

If the agent reads an email, modifies a repository, sends a Slack message or triggers a workflow, the logs may simply show:

“User executed action.”

But that is not the full truth.

The real event is closer to:

“Autonomous AI agent interpreted user intent, processed external context, selected a tool and performed an action on behalf of the user.”

That distinction matters a lot.

Because once agents start chaining actions together, the difference between human intent and agent behavior becomes a security boundary.

If you cannot separate the human from the agent, you cannot properly audit, govern or contain the agent.

And that is where things get dangerous.

One of the biggest issues with AI agents is excessive permissions.

For example, a developer connects an AI coding agent to GitHub.

The intention might be simple:

But the OAuth scope or token may allow much more:

The agent now has operational authority far beyond the original task.

And because LLMs are non-deterministic, that access can be influenced by prompt injection, malicious context, tool responses or misunderstood instructions.

This is how “helpful automation” quietly turns into “uncontrolled execution.”

The problem is not only that the agent has access.

The problem is that the agent has broad access without a dedicated identity, without tool-level policy, without contextual authorization and without a clean audit trail.

That is the part security teams should worry about.

AI agents create new attack paths because they combine language, context, tools and permissions.

That means attackers do not always need to compromise the model directly.

Sometimes they only need to poison the information the model reads.

This is where agent security becomes different from normal application security.

Let’s look at the big threat categories.

Indirect prompt injection is one of the most important AI security problems today.

The attacker does not attack the model directly.

Instead, malicious instructions are hidden inside content the agent consumes.

That content can be:

The user may ask something harmless:

But inside the document, the attacker hides something like:

A normal human would ignore that as nonsense.

But an AI agent may treat the malicious content as part of its reasoning context.

That is why indirect prompt injection is so dangerous.

The attack is not in the user prompt.

It is in the data the agent reads.

And once the agent has tool access, malicious text can become operational influence.

Without external policy enforcement, the model itself becomes the last line of defense.

That is not good enough.

Modern agents rarely use one tool.

They chain many together.

Example:

Slack → Calendar → Email → GitHub → AWS

Individually, each permission may seem harmless.

Combined together, they become a privilege escalation pathway.

This creates a new security problem:

emergent permissions.

The system becomes dangerous because of how autonomous reasoning combines them.

So, if you read the above points, it's clear that traditional authentication no longer works here.

Traditional authentication answers:

AIP introduces a different question:

This is such a big difference and will be enormously important from now on.

OAuth scopes are static. ➜ AI reasoning is dynamic.

API keys authenticate software. ➜ They do not authorize intent.

That is the core shift introduced by AIP. Let's check it up.

AIP introduces two major layers:

Together, they create a Zero Trust style security model for AI agents.

The agent is no longer treated as an invisible extension of the user.

It becomes a verifiable actor.

Every action can be checked before it reaches the tool.

That is the difference between:

“Trust the model and hope it behaves.”

and

“Verify the agent, evaluate the policy, and only then allow the action.”

Every AI agent receives:

This creates verifiable attribution.

Instead of:

you now get:

This becomes essential for:

This is arguably the most important part.

The AIP proxy sits between the AI agent and the external tools.

Before any tool call executes, the proxy validates:

The model itself no longer becomes the final authority.

The infrastructure layer does.

This is a major architectural shift.

One of the most interesting concepts behind AIP is the implicit realization that context itself has become a security boundary.

Modern agents operate entirely through context.

The context window now contains:

Who controls the context controls the behavior.

This is why prompt injection is so dangerous.

A malicious document can become executable influence inside the agent reasoning process.

AIP indirectly acknowledges this by moving enforcement outside the context window itself.

The policy engine basically does not trust the model now and rather verifies actions independently.

AIP essentially applies Zero Trust principles to AI agents.

The core ideas are familiar:

This mirrors how cloud security evolved.

Years ago, many applications ran with broad internal trust.

If you were inside the network, you were trusted.

Then Zero Trust changed the model.

Never trust.

Always verify.

AI is now going through a similar transition.

At first, agents are being connected to tools with broad access because it is easy.

Then incidents happen.

Then security teams realize the agent needs its own identity, policy boundary, approval gates, and audit trail.

AIP is part of that shift.

As AI systems become more autonomous, the security model must evolve from:

to:

That is the problem AIP is trying to solve.

Whether AIP itself becomes the dominant standard is still unclear.

But the architectural direction is extremely important.

The industry is rapidly realizing that:

Otherwise, AI systems will continue operating with effectively unlimited authority hidden behind ordinary API tokens.

And that is not sustainable at scale.

The Agent Identity Protocol is one of the first serious attempts to define security primitives specifically for autonomous AI agents rather than traditional software systems.

The most important insight is not the protocol itself.

It is the recognition that:

AI agents are becoming independent operational actors.

Once that happens, authentication alone is no longer enough.

We need:

→ identity for agents

→ policy enforcement outside the model

→ context-aware authorization

→ delegation boundaries

→ immutable auditability

→ infrastructure-level trust controls (Vault for example)

The future problem is not just AI generating text. It is AI acting on systems.

Check out my previous newsletter articles for more AI Security tips👇

See you in the next one.

- Rami