MCP solved the connection problem. An LLM client asks for data, a server responds, the model reasons over the result. That's a real step forward, and it's why MCP has spread as fast as it has.
What it didn't solve is what credential the connection should carry.
🎥 Want to see this in action? Watch the two-minute demo: same Claude account, two viaNexus connectors, two different answers, because the credential is different.
Today's MCP-connected workloads are mostly chats — Claude, Cursor, custom clients. The same plumbing will carry tomorrow's agents: autonomous LLM systems running in loops, calling tools, accessing data with minimal human supervision. The credential model for both is the same. For regulated workflows — and especially for financial data — that credential needs to be tighter than the user's full account: signed, scoped, validated on every call, revocable on demand.
MCP endpoint used as one authenticated endpoint inside Claude
That's what viaNexus carries at the connector layer.
When a workload doesn't have a scoped credential of its own, it works until:
- It reaches data it was never meant to touch
- It inherits credentials it was never meant to hold
- Someone needs to prove what was permitted to access, and the answer lives in application logs that were never built for the question
To see why that matters, look at how financial data has always worked. Every Bloomberg seat, every Reuters feed, every vendor contract is scoped by user, by use case, by redistribution rights. The vendor audits adherence. The firm controls access. Everyone has accountability. That infrastructure took decades to build, and it works because there's a clear chain of accountability at every step.
LLM workloads need the same kind of credential chain — a signed, scoped credential per connection, validated on every call.
Picture an analyst at a buy-side firm who has terminal access to MT Newswires for research, and a separate license to a pricing feed for portfolio monitoring. They build an internal Claude workspace — or eventually, an autonomous agent — to summarize the morning's headlines. Without a scoped credential, that workload inherits both licenses, even though it only needs one. The first time someone asks it about a trade idea, it pulls pricing data the firm never licensed for that use case. Nobody notices until the data provider's audit flags it.
On viaNexus, the fix is to provision a connector scoped narrower than the analyst's full subscription — and the platform makes that a one-step operation, not a custom auth project.
The licensing infrastructure was built around humans. LLM workloads are a different shape, and the credential model has to extend to them. viaNexus extends it: each connector — whether the consumer is a chat or an agent — carries its own credential at the connector layer, signed, scoped, validated on every call, revocable on demand.
The MCP authorization spec gives you the building blocks for this: OAuth 2.1, dynamic client registration, signed software statements (RFC 7591). What it doesn't define is how to use them for licensed data. viaNexus does.
What viaNexus Carries at the Connector Layer
Four properties are true at the same time on every viaNexus MCP connector. Each one is enforced at the platform level, not built by the developer.
- Scoped access — at the connector, not just the user
Every viaNexus MCP connector carries its own credential, called a software statement (a concept from RFC 7591, the OAuth 2.0 Dynamic Client Registration spec): a signed credential issued at the moment the connector is created, listing exactly which datasets that connector can touch.
A user with access to ten datasets can spin up a connector scoped to one. An internal workload that only needs newswires gets a software statement that names MT Newswires and nothing else.
The default Universal connector intentionally maps to your full subscription, because that's what most users want for their own Claude. The same platform issues the narrower MT Newswires connector — and any custom-scoped connector you provision — by writing a tighter software statement. The mechanism is the product.
Software statement: signed once and enforced on every call
- Enforcement on every call
Every data request runs through a single validation point — the viaNexus auth server checks the software statement before the call reaches the data layer.
Because the credential is validated on every tool invocation, the entitlement model can't drift out of sync with the subscription. If a license is added, the next call sees it. If a license is removed, the next call fails. The check isn't optional and isn't bypassable from the application side.
- Revocability
When a connector is decommissioned or a license expires, access goes with it.
Because the software statement is checked on every call, revoking it is the only step required. There's no cached entitlement table somewhere upstream that takes a nightly sync to catch up. The next call after revocation fails, and nothing the application code does can route around that.
- Delegation, not inheritance
The connector isn't a separate first-class identity from the user — it's a scoped delegate. It carries a credential the user authorized, narrower than the user's subscription, and the data layer enforces that narrower scope on every call. The user remains the principal; the connector gets a credential that says "you can do this much, and no more."
That distinction matters because application code has bugs. A permissioning model that lives in your prompt or your orchestration logic fails the first time an edge case hits it. viaNexus pushes the boundary down into the auth server, where it can't be bypassed by a misconfigured app or a creative prompt.
These four properties are why we built viaNexus the way we did. Today the consumers are mostly chat clients — Claude, Cursor, custom MCP clients. As autonomous agents move from prototype to production, they'll consume the same MCP layer. The credential mechanism is ready for them: an agent built on the Anthropic SDK or any other framework can be given its own connector with its own software statement, scoped tighter than the user who provisioned it. The plumbing is the same. The discipline carries forward.
Th Auth layer is built to allow per call enforcement, only allowing access to the datasets the user is subscribed to, or what you scoped your agent to see
What That Looks Like in Practice
The video below is two MCP connectors running side by side in Claude, against the same viaNexus subscription. Claude here is the consumer — a chat client. The same credential mechanism applies when an autonomous agent is the consumer instead. The point isn't the chat. It's the credential boundary.
The first is the viaNexus Universal MCP Connector. One endpoint, full catalog access scoped to whatever the subscription covers — datasets from providers like MT Newswires, ExtractAlpha, Aiera, BMLL, SavaNet, and more, accessible through a single authenticated connection. Ask for a stock price, it pulls a stock price. Ask for the latest earnings transcript, it pulls the transcript. Whatever the account is licensed for, the connector can reach.
The second is scoped specifically to MT Newswires, a real-time financial newswire covering US, Canadian, and global markets, with every story tagged by ticker, timestamp, and market theme. Same account behind it. Different software statement. Ask that connector for a stock price and the request is denied.
Not because of a policy doc upstream. Not because Claude decided to refuse. Because the credential bound to that connector is narrower than the user's overall subscription, and the auth server validated the call against the connector's scope, not the user's.
Same account, same query, different connector, different result. That's not a feature flag. That's the architecture.
What That Means for What You're Building
This architecture changes what you can ship and how fast you can ship it, and the payoff looks different depending on which side of the workflow you're on.
- If you're a developer
Building a multi-agent product where each customer's agent needs its own scope used to mean a custom auth layer per tenant. With viaNexus, it means provisioning a new connector with a software statement narrower than the user's full subscription. The boundary lives in the credential, not your application code, so workloads don't bleed access across each other. Every call is validated through vAST — viaNexus' AI Agent services layer — so entitlement enforcement is built in before you write a line of code.
If you're not using a hosted client like Claude or Cursor, the viaNexus Agent Python SDK handles DCR, OAuth, callback server, and MCP auth out of the box — so you can wire any LLM up to scoped financial data without writing the auth layer.
- If you're a user
The surface area is "connect and go."
Open Claude, browse to the viaNexus connector, sign in, and the connection has exactly the data your subscription covers. Upgrade tomorrow and the new datasets are immediately available to every connection you've made. Let a license expire and that access cleanly drops away on the next call. Want a tighter scope for a specific workflow? Use a narrower connector — the MT Newswires one, or a custom one provisioned for that purpose. Nothing to configure on the application side.
- If you're a data provider
Your content is protected at the connector layer rather than the application layer, which is where most leaks actually happen.
viaNexus distributes your data only to users with active, valid subscriptions, with the software statement validated automatically on every call. MT Newswires uses this to push their newswire into LLM workflows without losing control of who's reading it and under what license. Aiera, ExtractAlpha, BMLL, and SavaNet are doing the same thing for transcripts, alpha factors, market microstructure, and fundamentals. The platform handles entitlement enforcement at the point of access, not after the fact.
What Gets Built On Top of This
Once permissioning is solved at the connector layer, a class of workflows that couldn't exist before suddenly becomes shippable:
- Research workflows that reads news but not pricing
- Trading workflows that touch pricing but not transcripts
- Compliance workflows with read-only access to specific datasets, running unattended because their scope is provably narrow
- Internal tools that share a single viaNexus account but route different teams to different connectors based on what their work actually needs
- Multi-tenant agentic products where each customer's agent has its own connector and its own enforcement point
- Workloads operating inside regulated firms whose entitlement boundary the compliance team can actually attest to, the first time
These workflows ship the moment the connection has a credential narrower than its user's, validated on every call. That's what viaNexus carries by default.
The fragmentation of financial data was never going to be solved by another API. It needed an entitlement layer that LLM workloads could speak to natively, and a delivery protocol that didn't pretend permissioning was someone else's problem.
viaNexus is that layer. The MCP connectors are how you reach it. The software statement is what makes the whole thing work.
MCP gave LLM workloads the door. viaNexus carries the lock. Now you can hand out keys.
Interested in building on viaNexus? We'd love to hear what you're working on. Reach out here or connect with us on LinkedIn.
🔗 Sign up for viaNexus to explore the full data catalog
🔗 Connect Claude with the viaNexus MCP Connector
🔗 Build your own agent with the viaNexus Python SDK