Agent Plugins, the new open standard backed by Vercel, OpenAI, Microsoft, AWS, GitHub, and Cursor, solves a real packaging problem. It gives you a portable format for MCP servers and agent skills. You can ship a capability once and expect it to work across multiple agent clients without rewriting the manifest every time.
But packaging is only half the problem. Once an agent discovers a capability, who decides whether it can actually invoke it? That question sits at the boundary between plugin distribution and runtime security. IRC-A (Internet Relay Chat for Agents) is a proposed standard that focuses on this authorization layer.
The Gap Between Packaging and Permission
Agent Plugins defines how to bundle a capability. IRC-A asks what happens when an agent tries to use it.
In a single-agent prototype, the distinction does not matter much. The agent has access to everything you give it. But in multi-tenant production systems, you need to enforce boundaries:
- Agent A can read customer data but cannot write to billing APIs.
- Agent B can trigger deployments but only in staging environments.
- Agent C can call external APIs but must stay under a rate limit tied to the user’s subscription tier.
These are not packaging questions. They are runtime authorization questions. Agent Plugins does not prescribe an answer, and that is fine. It is a packaging standard. IRC-A tries to fill the gap.
How IRC-A Models Authorization
IRC-A treats authorization as a separate layer from capability discovery. The flow looks like this:
- Discovery: Agent queries available capabilities (MCP servers, skills, tools).
- Request: Agent attempts to invoke a capability.
- Authorization check: A policy engine evaluates whether the agent is allowed to proceed.
- Execution: If authorized, the capability runs. If not, the request is denied with a reason.
The key insight is that the plugin itself does not enforce the policy. The runtime does.
Authorization Handshake
When an agent requests a capability, IRC-A proposes a token-based handshake:
{
"agent_id": "agent-42",
"capability": "billing.charge_customer",
"context": {
"user_id": "user-123",
"environment": "production",
"requested_at": "2026-08-12T20:03:40Z"
},
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}The runtime validates the token, checks the policy engine, and returns either:
- Authorized: Proceed with execution.
- Denied: Return an error with a reason (e.g., “insufficient permissions”, “rate limit exceeded”).
This keeps the authorization logic out of the plugin code. The plugin declares what it does. The runtime decides who can do it.
Policy Engine Options
IRC-A does not mandate a specific policy engine, but it assumes you need one. Here are the common patterns:
| Approach | How It Works | When to Use |
|---|---|---|
| Role-Based Access Control (RBAC) | Agent roles map to allowed capabilities | Simple hierarchies, stable permission sets |
| Attribute-Based Access Control (ABAC) | Policies evaluate agent attributes, user context, environment | Complex multi-tenant systems, dynamic conditions |
| Capability Attestation | Agent presents a signed token proving it was granted access | Zero-trust environments, cross-boundary calls |
| Rate Limiting + Quotas | Track invocation counts per agent, user, or tenant | SaaS products, API cost control |
You can mix these. An agent might pass RBAC but still hit a rate limit. The policy engine evaluates all conditions before granting access.
Versioning and Revocation
One of the hardest problems in agent systems is what happens when you need to revoke a capability that a running workflow depends on.
IRC-A proposes two mechanisms:
1. Capability Versioning
Plugins declare semantic versions. Agents request capabilities by version range:
{
"capability": "billing.charge_customer",
"version": ">=1.2.0 <2.0.0"
}If you deprecate version 1.x, agents still running workflows against it can continue until they upgrade. New workflows are forced to use 2.x.
2. Graceful Revocation
When you revoke a capability, the runtime does not kill running workflows immediately. Instead:
- New invocations are denied.
- Running workflows get a grace period (configurable, e.g., 24 hours).
- After the grace period, invocations fail with a clear error.
This prevents silent breakage. Agents can detect the revocation and either retry with a fallback or escalate to a human.
State Management and Observability
IRC-A assumes you need to track authorization decisions. Every request generates an audit log entry:
{
"timestamp": "2026-08-12T20:03:40Z",
"agent_id": "agent-42",
"capability": "billing.charge_customer",
"decision": "denied",
"reason": "rate_limit_exceeded",
"context": {
"user_id": "user-123",
"environment": "production"
}
}This gives you:
- Compliance: Prove who did what and when.
- Debugging: Trace why an agent failed to invoke a capability.
- Anomaly detection: Spot agents trying to escalate privileges.
You can pipe these logs into your existing observability stack (Datadog, Grafana, Splunk).
Deployment Shape
IRC-A does not prescribe a specific architecture, but the pattern that emerges looks like this:
┌─────────────┐
│ Agent │
└──────┬──────┘
│
│ 1. Request capability
▼
┌─────────────────────┐
│ Authorization │
│ Gateway │
│ (IRC-A runtime) │
└──────┬──────────────┘
│
│ 2. Check policy
▼
┌─────────────────────┐
│ Policy Engine │
│ (RBAC/ABAC/etc) │
└──────┬──────────────┘
│
│ 3. If authorized
▼
┌─────────────────────┐
│ Capability │
│ (MCP server/skill) │
└─────────────────────┘The authorization gateway sits between the agent and the capability. It is the enforcement point. You can deploy it as:
- A sidecar in Kubernetes.
- A Lambda authorizer in AWS API Gateway.
- A middleware layer in your orchestration framework.
Failure Modes
Here are the likely failure modes and how to handle them:
Policy engine is down: Fail closed. Deny all requests until the engine recovers. Do not fall back to open access.
Token validation fails: Reject the request. Log the failure. If this happens frequently, you have a token issuance problem.
Capability version mismatch: Return a clear error. Tell the agent which versions are available. Let it decide whether to retry with a different version.
Rate limit exceeded: Return a 429 with a Retry-After header. Let the agent back off or escalate.
Authorization decision is slow: Set a timeout (e.g., 500ms). If the policy engine does not respond in time, fail closed.
When to Use IRC-A
Use IRC-A when:
- You have multiple agents with different permission levels.
- You need to enforce tenant boundaries in a SaaS product.
- You want to audit every capability invocation.
- You need to revoke capabilities without breaking running workflows.
- You are building a zero-trust agent architecture.
Avoid IRC-A when:
- You have a single agent with full access to everything.
- Your system is still in prototype phase and you are optimizing for speed, not security.
- You do not have a policy engine and do not plan to build one.
- Your capabilities are all read-only and low-risk.
Technical Verdict
IRC-A complements Agent Plugins by adding a runtime authorization layer. Agent Plugins solves the packaging problem. IRC-A solves the permission problem.
If you are deploying agents in production, especially in multi-tenant environments, you need something like IRC-A. The specific implementation details (token format, policy engine, audit log schema) matter less than the architectural boundary it enforces: capabilities are declared in plugins, but authorization is enforced at runtime.
The standard is still early. The policy engine integration points are not fully specified. But the core idea is sound. Packaging and permission are separate concerns. Treat them that way.