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 (21)
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.
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 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.
Packaging a capability makes it portable, but runtime authorization is what determines whether that capability is actually safe to use. One thing I find particularly important is keeping discovery separate from authorization: semantic search can help an agent find a tool, but it should never be the reason that tool becomes accessible. That boundary becomes critical once agents can discover capabilities dynamically.
Packaging and runtime governance are distinct layers, agreed. The detail I would press on is that a short-lived signed token is only as safe as the decision it binds.
The token should name the subject and delegating actor, tenant, audience/server identity, exact capability plus schema/version digest, canonicalized parameter constraints, purpose, resource scope, side-effect class, expiry, nonce/delegation depth, and approval/decision ID. The tool must re-authorize those claims against current local policy at dispatch—not treat a valid gateway signature as permanent permission. Revocation and emergency deny need to beat token expiry.
Semantic discovery also needs a security evaluation of its own. An attacker can craft descriptions that rank into privileged channels or exploit stale embeddings after a capability changes. Filter by hard authorization before vector ranking, sign registry metadata, bind results to identity/version digests, and test adversarial descriptions, channel-crossing attempts, stale caches, plugin replacement, replay, and confused-deputy delegation.
Finally, keeping business payloads out of the gateway helps confidentiality, but authorization often depends on payload semantics. A useful split is gateway-issued coarse delegation plus tool-owned fine-grained policy and typed validation. That preserves isolation without turning the gateway into an omniscient policy oracle—or the token into a bearer-shaped bypass.
This is exactly the kind of feedback I was hoping for. Agreed: a signed token is only as safe as the decision it binds, and “valid gateway signature” must never become permanent permission.
A human analogy: I am the agent. My manager/security office is the gateway/directory — it knows which application can solve my task and issues a bounded authorization for that specific task. The signed authorization is the DET — the work order I hand to the datacenter guard. The application/datacenter guard is the MCP: even if I arrive with a valid signed order, it still checks identity, role, exact rack, exact task, time window, and current revocation state before opening the door. The badge gets me to the door. The MCP decides whether the drawer opens.
For transparency: the current implementation already signs DETs as PASETO v4.public with
iss,sub,aud,permitted_action,restricted_params,jti,iat, and a shortexp. I’m not presenting that as finished — I’m presenting it as the current baseline. The next hardening step is to formalize the required DET contract: tenant, delegating actor, role, capability schema/version digest, canonicalized parameter constraints or digests, purpose, resource scope, side-effect class, nonce/delegation depth, approval/decision ID, and revocation class.On parameter injection, we agree: execution must be authorized only for one exact action with strict parameters. The DET should bind
permitted_action, schema/version digest, and a canonical digest of the exact arguments. Raw sensitive arguments travel only in the direct mTLS invocation to the MCP; the MCP canonicalizes them, recomputes the digest, and rejects any mismatch. Non-sensitive constraints can remain explicit inrestricted_params(max amount, currency, channel, side-effect class), but confidential values should be bound as hashes/commitments.Agents should also be first-class machine identities linked to enterprise roles, the same way people are linked to IAM groups. A
sales_agentmay create sales; amanagement_agentmay only query. If node A belongs to sales,create_salecan be allowed; if node D belongs to management, a valid signature still does not makecreate_saleallowed. A compromised agent should mean a compromised role, not a compromise of the whole network.For revocation, expiry alone is not enough. The same hot path used to register capabilities needs a symmetric hot-revocation path — a signed API/cURL operation that can revoke a
jti, node, role, capability, tenant, or channel and propagate deny state to MCP servers. High-risk side-effect classes should check fresh deny state before execution, while low-risk reads can remain offline-verifiable inside a very short TTL. The gateway stays out of business payloads, but revocation state has to beat token expiry.Same on semantic discovery: embeddings should rank only after hard authorization has already masked the space. Registry metadata should be signed, results bound to identity/version digests, and the threat model should explicitly test adversarial descriptions, channel-crossing, stale caches, plugin replacement, replay, and confused-deputy delegation. Discovery is an optimization layer; authorization is not allowed to be semantic.
And yes on payload semantics: the gateway is an observer/delegator and capability directory. It has no low-level access, no drivers, no credentials, and no business memory. It receives a minimal intent to resolve who can help, signs a bounded delegation, and then the agent makes the direct call. Keeping business payloads out of the gateway helps confidentiality, but fine-grained authorization often needs payload context — so the split I like is gateway-issued coarse delegation plus MCP-owned typed validation and local policy. The gateway should not become an omniscient oracle, and the token should not become a bearer-shaped bypass.
I’ll turn this into a tracked security-invariants checklist in the whitepaper/profile: required DET claims, canonicalization/digest rules, role mapping, revocation classes, discovery-poisoning tests, and MCP-side dispatch checks.
The channel model gives you at-least-once delivery, so a short-lived token can authorize the same execution twice if a retry lands after the ack is lost. Worth binding an idempotency key into the signed decision itself and having the capability pool reject the second use, otherwise the audit trail records one approval and two side effects. I keep the dedup table in SQLite next to the audit rows so a crashed run resumes without re-executing: gist.github.com/renezander030/8a23...
Great point — and I think it defines the boundary precisely. At-least-once delivery is a channel property; exactly-once business effect cannot be solved by the BFA without turning it into a transaction manager. So my split is: BFA issues bounded authority, the agent performs the call, and the MCP owns execution and outcome.
The single-use unit is not the token alone, but the (call, DET) pair. If the MCP never validated or executed, the DET remains valid inside its TTL and a retry is just a retry. If the MCP committed, that pair is burned and the MCP is responsible for answering executed / failed / pending / already applied.
The datacenter analogy fits audit too: the BFA is the manager signing the work order; the MCP is the datacenter. The security log at the door can prove that A arrived with a signed order to execute X at a given time and was allowed in. It does not prove the task succeeded. The exit log proves A left. The application log that says executed / failed / pending / rolled back belongs to the application itself.
For read-only capabilities, signed parameters make a retry repeat the same query. For side-effecting capabilities I agree an idempotency/execution record is needed — but it should live next to the MCP/business audit rows, not in the BFA. The signed decision can carry decision_id/params_digest; the MCP keeps the dedup/execution record atomically with its audit row. Your SQLite-next-to-audit pattern is exactly where I would put it.
That gives full evidence without centralizing business retries: BFA issuance logs prove what was authorized; MCP validation/access logs prove the DET was presented and accepted at the boundary; MCP application logs prove what happened. decision_id/jti correlates them. No bearer-shaped bypass, but also no gateway-turned-transaction-manager.
Really interesting perspective. I like the separation between packaging a capability and deciding what it is actually allowed to do at runtime. That feels like an important piece of the agent architecture puzzle, especially when you start thinking about security and real production systems.
Thanks — that separation is the whole bet. Packaging should make capabilities portable; runtime should make them governable. Once agents touch production, “what it can advertise” and “what it is allowed to do right now” have to live in different layers.
I’d love to hear where you think the boundary breaks first: semantic discovery, delegated authorization, or MCP-side enforcement.
@sandrog exactly. a signed manifest is integrity of the claim, not authority to act. the distinction maps cleanly to the web's own split: TLS proves who sent it, not that they should have. the runtime that conflates those two has built the same mistake in a new coat. the attestation chain is what's missing. a verifiable trail from 'manifest advertised X' through 'runtime granted X' to 'agent executed X'. without the middle link, we're back to trusting the bearer of the signed document.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.