DEV Community: MudraID

Your AI Agent Has API Access. But Who Decides What It Can Do?

MudraID — Fri, 13 Nov 2026 03:21:01 +0000

AI agents are becoming a normal part of modern applications.

Developers are building agents that can query databases, call APIs, automate workflows, interact with cloud services, and even coordinate with other agents.

Getting an agent to perform a task is becoming easier.

But there's another question we need to think about:

Just because an AI agent can access a system, does that mean it should be allowed to perform every action?

That's where things get interesting.

The Problem With Giving AI Agents Too Much Access

Imagine you've built an AI agent to help manage customer support requests.

It needs to:

Read customer information.
Create and update support tickets.
Retrieve order details.
Send responses to customers

Everything works perfectly during testing.

But what happens if that same agent can also delete customer records, modify payment information, or access unrelated internal systems?

The agent may never need those permissions.

Yet developers sometimes give agents broad API access because it's easier to get an integration working.

This creates a security risk.

An agent can behave unexpectedly, misunderstand instructions, or be manipulated through malicious content.

Even when an agent is operating as designed, excessive permissions can increase the impact of mistakes.

API Authentication Isn't the Same as Authorization

Let's say an AI agent uses an API key to connect to your application.

The API recognizes the key and accepts the request.

But what does that actually prove?

It proves that the request includes a valid credential.

It doesn't necessarily prove that the agent is authorized to perform the specific action.

For example:

DELETE /api/customers/123 Authorization: Bearer <agent_token>

A valid token should not automatically mean the agent can delete customer records.

The system needs to evaluate additional information.

Which agent is making the request?

Who delegated authority to that agent?

What actions is it permitted to perform?

Is that permission still valid?

These questions become especially important when agents operate autonomously.

Why AI Agents Need Their Own Identities

In many applications, AI agents operate using shared service accounts or credentials.

This can make it difficult to distinguish between individual agents.

Consider three agents working within the same organization:

AI Agent	Responsibility	Required Access
Support Agent	Customer inquiries	Read customer data
Finance Agent	Invoice processing	Read and create invoices
Reporting Agent	Analytics	Read reporting data

Each agent has a different purpose.

They shouldn't all receive identical permissions.

Giving agents distinct, verifiable identities creates a foundation for more precise access controls and accountability.

It also makes it easier to understand which agent initiated a particular request.

Delegated Permissions Matter

AI agents often perform actions on behalf of someone else.

For example, a user might ask an agent to generate a financial report.

The agent may need temporary access to financial data to complete that task.

But that doesn't mean it should receive unrestricted access to the organization's financial systems.

A better approach is to delegate only the permissions required for the task.

For example:

{ "agent_id": "reporting-agent-01", "delegated_by": "user-123", "permissions": [ "reports:read", "reports:generate" ], "expires_at": "2026-11-13T18:00:00Z" }

This is an illustrative authorization-policy example, not a MudraID API payload.

The idea is simple:

Give agents the authority they need, for only as long as they need it.

What About Agents That Use a Browser Instead of APIs?

Not every AI agent interacts with systems through an API.

Some agents operate through browsers, desktop applications, or existing authenticated sessions.

These agents introduce another challenge.

An agent using an already logged-in browser session may inherit the user's permissions without presenting a separate agent-specific credential.

In that situation, API-level authorization alone may not provide enough visibility or control.

Developers may need additional protections, such as isolated execution environments, restricted accounts, explicit approval for sensitive actions, and application-level authorization checks.

The enforcement point matters just as much as the identity model.

**Where MudraID Fits In

**
At Decryptogen, we're developing MudraID, identity and trust infrastructure designed for AI agents.

MudraID focuses on three important areas:

1. Verifiable agent identities

Establishing a reliable identity for an AI agent so systems can distinguish it from other agents and services.

*2. Secure delegation of authority
*
Helping organizations define and manage what an agent is authorized to do.

3. Real-time verification

Supporting verification of an agent's authority when it requests access to protected resources.

The goal is to make AI agent identity and authorization an intentional part of application architecture rather than an afterthought.

Of course, identity infrastructure is only one part of AI security. Applications still need proper authorization enforcement, monitoring, secure credential handling, and appropriate human oversight.

A Question for Developers Building AI Agents

As agentic systems become more common, we'll need to think more carefully about how permissions are managed.

A few questions worth discussing:

Are your agents using individual identities or shared credentials?
Are permissions enforced at the API gateway, application layer, or somewhere else?
How are you handling agents that operate through existing browser sessions?
Can you revoke an agent's access without disrupting other services?

I'm particularly interested in how teams are handling this in production.

How are you currently managing identity and permissions for AI agents?

Would love to hear what approaches are working for you.

Explore MudraID: https://mudraid.ai

**Documentation: **https://docs.mudraid.ai/overview/introduction

How Do You Secure AI Agents That Have Access to Your APIs?

MudraID — Thu, 05 Nov 2026 04:43:46 +0000

AI agents are starting to do more than answer questions.

They can call APIs, update databases, retrieve customer information, and trigger workflows without someone manually approving every step.

That's useful, but it also raises a question:

How do we make sure an AI agent only does what it's allowed to do?

The Problem With Giving Agents API Keys

Let's say you've built an AI agent that helps your support team.

It needs to read customer records, check order details, and occasionally update a support ticket.

The easiest approach is to give it an API key with access to those systems.

But what happens if that key also allows the agent to delete customer records or modify payment information?

The agent might never need those permissions, yet it still has them.

And things become more complicated when one agent starts calling another.

What Happens When Agents Work Together?

Imagine a simple workflow:

Agent A receives a customer request.

Agent A asks Agent B to retrieve information.

Agent B calls an internal API.

The API returns sensitive customer data.

Now consider a few questions.

How does the API know which agent made the request?

How do we know Agent B was actually authorized by Agent A?

And what happens if Agent B tries to access something outside the original task?

These are problems that traditional API authentication doesn't always solve on its own.

A Better Way to Handle Agent Access

There are a few approaches worth considering.

Give each agent its own identity

Instead of sharing credentials, each agent should have an identity that can be verified.

Limit permissions to the task

An agent that only needs to read customer information shouldn't receive permission to modify or delete it.

Verify access when requests happen

Authentication alone isn't enough. The system should also check whether the agent is authorized to perform the specific action.

Track agent activity

When something goes wrong, developers need to know which agent performed an action and under what authority.

Where MudraID Fits In

We've been exploring these challenges while working on MudraID at Decryptogen.

MudraID focuses on identity and access management for AI agents, including verifiable agent identities, secure delegation of authority, and real-time access verification.

The goal is to help developers manage agent permissions without relying entirely on shared credentials or scattered access rules.

You can learn more at https://mudraid.ai/.

What Are Developers Doing Today?

I'm curious how other teams are approaching this.

Are you using OAuth scopes, short-lived tokens, API gateways, or custom permission checks?

And if you're running multiple agents in production, how are you handling permissions when one agent delegates work to another?

Would be interested to hear what's working and what has been difficult to implement.

How to Secure Autonomous AI Agents with Verifiable Identity

MudraID — Mon, 19 Oct 2026 13:11:06 +0000

AI agents are starting to do more than generate text or answer questions.

They can retrieve information, call APIs, interact with databases, and carry out tasks across different systems. Some can even coordinate with other agents to complete workflows without constant human involvement.

That's useful. But it also introduces a security problem that deserves more attention.

When an AI agent takes an action, how do we know which agent it is, who authorized it, and whether it should still have permission?

For developers building agentic applications, these questions are becoming increasingly important.

The identity problem in agentic AI

Consider a customer service AI agent that can retrieve account information, update customer records, and initiate refund requests.

In a traditional application, a user signs in and receives permissions based on their role.

With an autonomous agent, the situation becomes more complicated.

The agent may act on behalf of a user, communicate with other services, and execute several actions as part of a single workflow.

If the agent operates using a shared API key or a broadly privileged service account, it can become difficult to distinguish its actions from those of other agents.

This creates several challenges:

Identifying which agent initiated a request.
Determining who authorized the agent.
Restricting access to specific tasks.
Revoking permissions when circumstances change.
Maintaining an audit trail of agent activity.

The problem isn't simply authentication. It's establishing identity, authority, and accountability throughout an agent's lifecycle.

Why traditional IAM alone may not be enough

Identity and Access Management (IAM) systems are essential for enterprise security.

They help organizations authenticate users and workloads, manage permissions, and control access to resources.

These capabilities remain important for AI agents.

However, autonomous agents introduce additional requirements.

An agent might receive a task from a user, delegate part of that task to another agent, access several APIs, and make decisions based on information received during execution.

The security system needs to understand more than whether the agent possesses valid credentials.

It also needs to determine whether the requested action falls within the authority granted to that agent.

Existing IAM infrastructure can support these requirements, but developers may need additional agent-specific identity and authorization controls.

*1. Give every AI agent a verifiable identity
*
The first step is making agents identifiable.

Instead of allowing multiple agents to operate under the same credentials, each agent should have a distinct identity that can be authenticated.

This helps organizations distinguish between agents, associate actions with specific identities, and apply appropriate permissions.

A verifiable agent identity also provides a foundation for secure agent-to-agent communication.

For example, when Agent A requests information from Agent B, the receiving system should be able to establish which agent initiated the request before deciding whether to authorize it.

Identity establishes who is requesting access. Authorization determines what that identity is allowed to do.

Both are necessary.

2. Delegate authority instead of granting unrestricted access

An AI agent rarely needs unlimited permissions.

Imagine an agent responsible for preparing a monthly financial report.

It may need permission to read selected financial records and generate a summary.

It probably doesn't need permission to modify bank account information or approve payments.

A better approach is to grant scoped authority based on the task.

For example:

Agent: Financial Reporting Agent
Authorized action: Read approved financial records
Resource: Reporting database
Permission duration: Until the reporting task expires
Restricted actions: Payments, account modifications, and administrative changes

This is an illustrative policy, not a MudraID API configuration.

Scoped delegation helps reduce the potential impact of compromised agents, unexpected behavior, or overly broad tool access.

3. Verify authorization when actions happen

Authentication should not automatically provide unlimited authority for the rest of an agent's execution.

An agent's permissions may change while a workflow is running.

A user might withdraw authorization. A security administrator might revoke access. A particular action might require additional approval.

This makes request-time authorization especially important.

Before a sensitive operation is executed, the relevant system should evaluate the agent's identity, the requested action, the resource, and the authority currently granted.

Consider an agent that was previously authorized to retrieve customer records.

If its permission has been revoked, a later request should not succeed simply because the agent authenticated earlier.

Authorization must reflect the current security policy.

4. Make revocation part of the design

Revocation is often overlooked when developers focus on getting an AI-agent workflow running.

But what happens if an agent starts behaving unexpectedly?

What if a user cancels a task?

What if an agent's credentials are compromised?

Security teams need a reliable way to withdraw access.

Effective revocation also requires enforcement. Removing a permission from a database is not enough if downstream systems continue accepting previously issued authority.

Developers should consider credential lifetimes, cached authorization decisions, active sessions, and how quickly revoked permissions take effect.

5. Maintain accountability across agent workflows

When multiple agents participate in a workflow, investigating an unexpected action can become difficult.

Suppose one agent receives a request, another retrieves data, and a third performs an operation.

If something goes wrong, the organization needs to understand the sequence of events.

Useful audit information may include:

Which agent initiated the action.
Which identity or user delegated authority.
What operation was requested.
Which resource was accessed.
Whether the request was authorized.
When the activity occurred.

Auditability helps teams investigate incidents, understand agent behavior, and improve governance.

It should be designed into agent workflows rather than added only after a security incident.

Where MudraID fits

These are the kinds of challenges we're addressing with MudraID, an AI-agent identity and trust platform developed by Decryptogen.

MudraID focuses on providing identity and authorization infrastructure for autonomous agents, including:

Verifiable agent identities.
Secure authentication.
Delegated authority and access control.
Real-time verification.
Access revocation.
Agent activity monitoring and auditability.'

The objective is to help organizations establish clearer boundaries around what their AI agents can access and perform.

As enterprises adopt increasingly autonomous workflows, agent identity should become part of the security architecture from the beginning.

*Final thoughts
*
Building capable AI agents is only part of the challenge.

Developers also need to consider how those agents are identified, what authority they receive, how their permissions are enforced, and what happens when access must be withdrawn.

These questions become especially important when agents interact with financial systems, customer information, administrative tools, or other sensitive resources.

The next generation of AI applications will need more than intelligent agents.

It will need agents that can be identified, authorized, controlled, and held accountable.

How is your team currently handling identity and delegated permissions for autonomous AI agents?

I'd be interested to hear what approaches developers are using.

Learn more about MudraID: https://mudraid.ai