Yesterday I stumbled on a LinkedIn post about a new open standard for packaging Agent Skills and MCP servers: Agent Plugins, built with collaboration from players like Vercel, OpenAI, Microsoft, AWS, GitHub and Cursor.
I won't lie: at first, I felt that familiar punch in the stomach.
A while ago, I had already felt the first signal when I read an article by @lukeocodes about the transformation from MCP to stateless. That was part of the same direction I had been exploring for more than a month with IRC-A — Internet Relay Chat for Agents. Then this new standard showed up, and for a second the impostor syndrome came back. If you have ever felt that, I recommend this piece by @sylwia-lask . When I told her I was feeling exactly that, she gave me a few kind words that stayed with me.
My first thought was: “How come nobody saw this before?”
Then a better thought showed up: maybe people are seeing it now. Maybe some of us just noticed a little earlier that the agent era was starting to repeat mistakes that software engineering already spent the last 20 years fixing.
And that is exactly why I wanted to write this: not to compete with Agent Plugins, but to complement it.
Agent Plugins solves a real problem: packaging
The new standard matters because it attacks something very concrete: portability.
If every agent client asks authors to rearrange the same components in a different way, the ecosystem becomes repetitive and fragile. A shared format for Skills and MCP servers creates a clean floor. That is good for builders, good for clients, and good for the ecosystem.
But once capabilities are packaged, another problem starts to appear.
Not “how do we ship this capability?”
But “how do we govern what happens when an agent discovers and executes it?”
That is the layer I have been obsessing with.
The question that keeps me up at night
Today, a lot of multi-agent systems are still built like tightly coupled graphs. We hardcode flows, overload prompts with tool schemas, give conversational agents too much privilege, and then hope nothing weird happens.
But production systems do not run on hope.
So the questions I have been trying to answer with IRC-A are:
- How does an agent discover the right capability without carrying every API schema in its system prompt?
- How do we authorize one specific execution, with one specific set of parameters, for a short period of time?
- How do we audit and trace what happened across a decentralized agent network?
- How do we make sure a reasoning agent never touches database credentials directly?
- How do we isolate tools so prompt injection cannot become lateral movement?
- How do we add or remove capabilities without redeploying the whole orchestrator?
In other words: Agent Plugins may standardize the suitcase. IRC-A cares about customs, the boarding pass, and who is allowed to open the cargo door.
What IRC-A proposes
IRC-A is my attempt to bring old, battle-tested software engineering ideas into the agent era: Smalltalk-style message passing, IRC-like logical channels, capability pooling, secure-by-default SDK base classes, and a strict separation between reasoning and execution.
At a high level, the architecture looks like this:
- Cognitive agents are stateless. They reason, delegate, and compose answers, but they do not own database drivers or long-lived credentials.
- A BFA Gateway acts as registry, governance layer, and semantic customs office. It does not carry business payloads; it registers identities, capabilities, channels, and signs short-lived authorization.
- Capabilities are discovered semantically. Instead of stuffing every tool schema into every prompt, an agent asks the gateway what it needs, and the gateway resolves relevant capabilities through a vector index.
- Logical channels mask discovery. An agent should not even see capabilities outside its authorized channels.
- Execution happens through isolated MCP tool servers. Only the execution layer holds physical connections to core databases and enterprise APIs.
- Authorization uses ephemeral delegated execution tokens. The gateway mints short-lived signed tokens; the receiving tool verifies them offline and rejects anything outside scope.
That is the part I believe can complement the current wave: less prompt-bloat, less coupling, more auditability, more resilience, and a much smaller blast radius when something goes wrong.
I do not want to compete with Vercel. I want to build with that ecosystem.
As an Argentine developer, seeing Vercel push this space hits close to home.
Guillermo Rauch is Argentine too. I do not know him, but I would be lying if I said I am not hoping some of these messages eventually reach his radar. Not because I want to say “I did it first” — that does not matter. What matters is that the same problems are becoming visible to more people, and that means the timing is finally right. And also because another great-scale solution coming from the same South GBA would be genial!
I believe Agent Plugins is an important step for portability. I believe IRC-A can be a complementary step for secure runtime governance. But the biggest thing IRC-A brings to the table is plug-and-play capability: new agents and tools should be able to register, be discovered semantically, and start participating without rewiring the whole system. And I believe the next generation of agents will need both: portable capabilities and controlled execution.
So this is me putting the flag in the ground.
I am building the SDK, the framework, the diagrams, the whitepaper, and now the uncomfortable part: the marketing. Door to door. Message by message. A pulmón, while being unemployed, working on my startup — where this solution was born to solve the problem of connecting B2B agents on the same network — and trying to push through it.
But I am convinced this conversation needs to happen.
If you are building agent infrastructure, I would love your feedback. If you are working on MCP, agent runtimes, plugin standards, or secure execution boundaries, I would love to compare notes. And if this resonates with anyone around the Agent Plugins ecosystem, even better.
Not as competition.
As a complement.
Top comments (42)
@sandrog You are right that the BFA has no business logic, and I was not arguing it should. The gap I am pointing at is narrower: the DET's bounded execution contract prevents injection and loops, but it does not prevent an agent from invoking the right tool with the wrong parameters, because the DET is scoped to the capability and not to the context. The gateway is stateless by design, and that is correct. What is missing is a runtime assertion layer at the MCP that checks the invocation against the agent's own stated intent, not against the DET. The DET says you may call this tool. The MCP says this tool is available. Neither says this call is consistent with the plan the agent just declared. That is the gap I keep coming back to, and it is not a criticism of the BFA scope. It is a missing piece on the agent side, not the gateway side.
@nyx533 Exactly, each piece in its proper place.
What you’re describing, an agent calling the right tool with parameters misaligned with its internal plan, is fundamentally a cognitive consistency / guardrail problem on the agent side, not an authorization or infrastructure failure.
In IRC-A, the boundaries are explicit:
The DET (Security / Perimeter): Guarantees who is allowed to execute what, bounds the parameter envelope, and prevents prompt-injection privilege escalation or runaway loops.
The MCP (Resource Server): Validates deterministic constraints, schema typing, local business invariants, and DET authenticity.
If the MCP had to inspect whether the call aligns with the agent's internal plan, it would need to inspect the agent's cognitive scratchpad, history, or intent context. That would destroy black-box decoupling (Smalltalk-style message passing / A2A) and tightly couple the tool to the cognitive implementation of the caller.
Cognitive assertion belongs inside the agent’s own loop (pre-flight self-evaluations or output guardrails). Once the message hits the wire, the MCP only enforces deterministic boundary contracts.
Put yourself in the shoes of someone designing a large enterprise system: you have no idea what future capabilities will be needed next quarter, or how business requirements will evolve.
If you put business logic into the BFA, or force an MCP tool serving multiple departments to know specific caller contexts, you immediately collapse back into tightly coupled static graphs (DAGs). You’re forced to hardcode edges, manage internal wiring, and redeploy orchestrators every time a department changes a rule. That is precisely the architectural trap IRC-A was built to eliminate.
Today you deploy System A; next month you need to attach an entire new cluster of agents from Department B and have it be genuinely Plug & Play.
For that to work at scale, everything must remain strictly decoupled. Each piece knows its own bounded domain—and nothing else.
The agent owns its cognitive plan; the BFA owns semantic discovery and cryptographic delegation; the MCP owns deterministic local validation.
@sandrog Your SWIFT analogy maps cleanly onto auth and delegation. It maps less cleanly onto what the agent does after authentication. SWIFT executes format; an agent interprets goal within scope. The two failure modes are different. SWIFT errors are format violations. Agent errors are scope violations that read as success. Put the boundary in the IAM layer. Build it granular enough that 'all tools' is not a real permission.
@nyx533 Yeah, exactly that. "Agent errors are scope violations that read as success" is a great definition of the runtime problem.
That is precisely why IRC-A rejects global tool grants (all_tools) and enforces:
Granular Channel Masking: An agent can only semantically discover capabilities registered within its authorized logical channels.
Ephemeral DET Scoping: Tokens are minted strictly per action, per recipient, with bounded parameter constraints.
End-to-End Auditability & Traceability: Because each DET is cryptographically signed with identity, target tool, parameter digests, and short-lived timestamps, you get non-repudiable proof of who did what, when, and under which explicit authorization across the network.
If you want to see how this separation, IAM scoping, and auditing boundary work in code, I just published a 5-minute hands-on tutorial setting up a multi-agent medical clinic:
🔗 dev.to/irc-a/your-first-irc-a-netw...
It demonstrates how role-scoped channels, isolated MCP tools, and ephemeral tokens prevent scope leakage in practice. Really enjoyed this exchange!
@sandrog The pre-flight self-evaluation you're proposing is just another black box calling itself. You've moved the problem from the MCP boundary into the agent's own loop, but you haven't changed the nature of the problem. You've just renamed it from 'authorization' to 'cognitive consistency.' Both are the same hard question: how does a system audit its own reasoning when the reasoning is what it's auditing? The DET/MCP split is clean architecture. The agent-checking-itself is a hall of mirrors.
@nyx533 Think of it with a classic banking analogy:
If you intend to transfer $100 but mistype $1,000 in your app, the wire protocol (SWIFT or HTTPS) will not refuse the transaction saying: "Wait, was your inner cognitive plan actually $100?"
The Transport / Authorization Layer (DET/BFA): Verifies you are authenticated, signs the delegation ticket, and ensures the payload wasn't tampered with in transit.
The Destination Server (MCP): Owns the business rules—it checks if the account exists, validates schema types, and verifies whether the $1,000 exceeds allowed account limits or available balance.
The User / Client (Agent): The only layer that knew the original intent was $100.
There is a thin line between the business boundary and the user boundary:
The user/agent boundary is responsible for intent formulation, internal reasoning, and client-side assertions.
The business/resource boundary (MCP) is responsible for domain rules, invariants, and state consistency.
If the network protocol or destination resource had to "audit the sender's mind" to guess whether $1,000 was a mistake, you would create an impossible recursive dependency.
An agent calling a tool with the wrong parameter isn't an infrastructure or protocol flaw—it's a client-side reasoning mistake.
Keeping deterministic assertions on the agent side, zero-trust delegation in the DET, and business rules inside the MCP keeps distributed architectures clean and decoupled. Each piece in its place.
Thanks so much for the kind words!
I really think your concept makes a lot of sense, and I can actually imagine agentic development moving in exactly this direction in the future. Have you thought about submitting this as a talk to some conferences? I think it could make a really interesting conference topic!
Thanks Sylwia, your words really helped.
I do think this movement is a must, but more than that, it feels like a paradigm change in how we program agents: from hardcoded graphs and prompt-stuffed tools to discoverable capabilities with governed execution.
I would love to submit it as a talk, but honestly I don’t know where to start. If you have any advice on CFPs or conferences that could fit this topic, I’d really appreciate it.
If capabilities resolve through a vector index, what stops a registered tool from writing its description to rank high for queries it has no business handling? Feels like SEO for tools and then the index itself becomes the thing you have to harden.
Nothing inside the embedding stops that — so the embedding cannot be the gate. But I also don’t want the BFA to own business rules. The split is: BFA does discovery hygiene; MCP does business permits.
A registered tool can write a great description, but before FAISS it still has to pass signed registration, provenance/publisher metadata, channel masking, health/revocation/version eligibility. Those are not permits to execute business actions; they are gates to avoid sending the agent to a spoofed or stale tool. Then similarity ranks only inside that eligible set.
Back to the manager analogy: my manager should not decide whether I may open a drawer inside the datacenter — the datacenter does that. But the manager must not send me to a lookalike datacenter because it had the best SEO.
BFA chooses the door. MCP decides if you may open the drawer.
Packaging capabilities is only half the problem. Runtime authorization has to answer who allowed this capability, for which task, with what expiry, and what evidence will exist afterward. Without that, plugins become a neat way to hide authority.
100% agree — and I think the “what evidence will exist afterward” part is the one people underestimate most. If a platform cannot reconstruct who approved which capability, for which task, and under which constraints, packaging can accidentally become a neat way to hide authority.
That is exactly where IRC-A tries to complement Agent Plugins: plug-and-play capability registration, semantic discovery after hard authorization, ephemeral signed delegation for one task/action, and MCP-side validation so execution leaves an auditable trace. Not a replacement for the packaging layer — a runtime governance complement.
Exactly. Packaging makes distribution easier, but authorization is where the blast radius is decided. I like capability manifests only when they are paired with runtime checks that can say "this call is not allowed in this context," not just "this plugin says it can do X."
In IRC-A, “context” has two layers: channel isolation decides what is even visible/discoverable; runtime authorization decides what is executable. A manifest can advertise “X”; a DET should bind X to subject, role, tenant, channel, action, parameter constraints and expiry; and the MCP still evaluates current local policy before touching drivers or APIs. Channels are the first context boundary — not the whole context.
That split makes sense. Discovery scope and execution authorization are different controls, and collapsing them makes the manifest look more powerful than it should be. I like the expiry point too; permission without time bounds gets stale fast.
Exactly. Expiry bounds the decision in time, but revocation has to be able to beat expiry for high-risk side effects. Discovery scope limits what can be found; execution authorization limits what can be done; audit records connect the two afterward. That keeps the manifest honest: portable, but never self-authorizing.
Great framing — packaging solves portability, but per-execution, short-lived authorization is where production systems actually fail. The 'isolate tools so prompt injection can't become lateral movement' requirement only holds if the capability manifest carries machine-readable policy (parameter allow/deny, credential classes, TTL) and the gateway signs short-lived grants the agent can't self-escalate. How does IRC-A handle the trust chain for that signing step?
Agents still have to comply with A2A.
Manifest says what exists. Issuer key says what was granted. MCP decides what runs.
The signing trust chain starts at enrollment, not at discovery. Each node has its own keypair and registers through a challenge-response handshake, so the BFA binds node_id, public key, role, tenant and channels before accepting capabilities. The gateway then has a separate issuer key, ideally protected in a KMS/HSM, with public key distribution and rotation for MCP verifiers.
After the channel mask and eligibility checks, the BFA signs a short-lived DET with that issuer key. The DET binds subject, audience, permitted action, parameter constraints or digest, side-effect class, jti, iat and exp. The agent cannot self-escalate because it never has the issuer private key, cannot alter signed claims without breaking verification, and still has no drivers or credentials.
The MCP verifies the DET offline with the gateway public key, then evaluates current local policy before touching anything. Manifest policy can be machine-readable input, but it is still an advertisement. The grant is the runtime decision. For high-risk actions, add approval_decision_id and fresh deny state so revocation can beat expiry.
The manifest declares what the agent CAN do. The runtime decides what the agent IS ALLOWED to do. Those are two different things and the gap between them is where the security model lives. Packaging capabilities without a runtime authorization boundary is just publishing a list of intentions. The authorization is the actual constraint, and it is runtime-specific. The manifest is an advertisement, not a guardrail.
That's the point! “advertisement, not guardrail” is a great way to put it. The manifest can declare capability metadata, but the allowed set is computed at runtime from identity, role, tenant, channel, action, parameter constraints, side-effect class and current deny state. Even a signed manifest only proves integrity of the advertisement; it does not prove permission to execute.
In IRC-A terms: packaging/manifests advertise what exists; the BFA resolves who can help under which channel and signs a bounded DET; the MCP enforces local policy before touching drivers or APIs. That keeps packaging portable without pretending the package format is the security boundary.
Manifest for discovery, runtime authorization for execution.
The separation between reasoning and execution is the part that stands out to me most.
I think there’s another governance problem that appears once capabilities become dynamic: authorization shouldn't only answer “can this agent use this tool?” but also “why is this execution allowed right now?”
A capability might be valid in general, but the current project context, decision history, or constraints could make a specific execution inappropriate.
That makes the execution boundary interesting not just as a security layer, but as a context-aware decision boundary between what an agent reasons about and what it is actually allowed to do.
Curious how you see that fitting into the short-lived authorization model.
This is a brilliant distinction! Moving from "Is this tool allowed for this agent?" to "Why is this specific execution allowed right now under this context?" is where real production governance lives.
In IRC-A, this flows directly through our multi-layered approach:
#finance-opsvs#public-support) are completely masked. The agent cannot even see, discover, or query tool schemas outside its channel space—to a compromised agent, non-authorized tools simply do not exist.permitted_action,canonical_param_digests, andpurpose_digest(ordecision_id). It becomes a signed, short-lived proof that says: "This agent, inside this authorized channel, was granted permission for this specific context under these parameters."The channel masks the space, the Gateway signs the contextual authorization, and the MCP enforces the local execution boundary.
Really glad you raised this point!
The customs metaphor is doing real work here: "Agent Plugins may standardize the suitcase. IRC-A cares about customs, the boarding pass, and who is allowed to open the cargo door." One layer I don't see addressed yet: the discovery index itself as an attack surface. If capabilities are resolved semantically through a vector index, a malicious tool can optimize its own description to rank for high-value queries, the tool-ecosystem equivalent of SEO squatting. Channels mask discovery across trust boundaries, but inside an authorized channel the nearest-embedding tool still wins the resolution. Who vets what gets registered, and does the BFA gateway score anything beyond similarity, like provenance or audit status, when it resolves a capability? That decision feels like the piece that determines whether semantic discovery becomes a strength of IRC-A or its softest entry point.
That is the soft spot, yes (the tool-ecosystem) version of SEO squatting. My rule is: description is data, not evidence, and similarity must never decide eligibility.
The current paper already points in this direction: §6.3 (“FAISS Capability Masking”) says unauthorized channels are metadata-filtered out before similarity is calculated, and §8 step 4 restricts the FAISS search to capabilities indexed under the shared channel before minting the DET. §4.2/§4.3 describe the registration and semantic discovery flow. What your comment adds is that inside an authorized channel, similarity alone is still too weak.
So the resolution order should be explicit: registration vetting first, signed node identity and challenge-response enrollment as in §5, then hard authorization before FAISS as in §6.3/§8, then policy filters, and only then vector ranking. A tool should not get into FAISS just because it submitted a nice description; it should carry signed identity, publisher/provenance metadata, tenant/role/channel binding, schema/version digest and audit status. For high side-effect classes, unsigned or unattested capabilities should be rejected or confined to a low-trust tier.
At query time, the BFA applies the channel mask and hard authorization before FAISS, then filters by provenance, trust tier, revocation state, health and version pinning. Similarity only ranks inside that eligible set, with deterministic tie-breakers. For high-value or high side-effect capabilities, nearest-embedding should not be enough: require an allowlisted capability ID, exact schema digest match, or an approved decision_id.
So yes, the gateway scores beyond similarity, but the security gates are boolean and dominate the ranking. The paper already has the mask; the hardening I’d formalize next is provenance/audit-aware resolution inside the masked set. Otherwise semantic discovery becomes the softest entry point instead of a strength.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.