In Today’s Issue:

🔓 The three permission models companies reach for first, and why each one fails

🔑 Why authentication was the easy part and authorization is the hard one

🔌 What a good MCP server does that a raw API cannot

🤖 Why an agent is an application, not an employee

🛡️ Why model guardrails are not a substitute for governance

⚖️ Who actually owns the failure when an agent gets it wrong

🌐 Why Arcade files an engineering ticket every time someone opens a browser

AI agents are rapidly moving from systems that answer questions to systems that send emails, update records, open tickets, and change production environments. But inside a real company, intelligence is only part of the problem. The harder question is whether an agent is allowed to take a specific action — and whether the company can prove afterward that it followed the rules.

To explore that challenge, Superintelligence Editor-in-Chief and Co-founder Kim Isenberg and Co-founder Peter Thum spoke with Alex Salazar, Co-founder and CEO of Arcade. Before founding Arcade, Salazar built an identity company that was acquired by Okta and later led developer products there. Arcade is building an action and authorization layer that connects agents to tools such as Gmail, Slack, GitHub, and enterprise systems without simply handing them unrestricted access.

Arcade raised a $60 million Series A in June 2026, led by SYN Ventures with Morgan Stanley and Wipro participating, which takes the company to roughly $72 million raised since it was founded in 2024. It also co-authored the authorization work that has since been accepted into the Model Context Protocol specification. That gives Salazar an unusually direct view of what actually stops an enterprise agent deployment, and it is almost never the model.

Where the problem sits. Agent authorization is the layer above tool calling, and the one most enterprises only discover once an agent tries to do something real. (Arcade)

This conversation has been edited for length and clarity.All the best,

Kim Isenberg

Kim Isenberg: You came out of Okta and the identity world before moving into AI agents. What made you realize that agent access control was not merely a product feature, but an infrastructure problem of its own?

Alex Salazar: Honestly, we stumbled into it. We originally started Arcade to build an agent for site reliability engineering. The idea was that it would receive an alert from Datadog or Grafana, diagnose what was happening, and interact with Jira, databases, and other parts of the production environment.

Then we realized that, for the agent to do its job properly, we would effectively have to give it super-admin access. No reasonable enterprise was going to allow that.

Because we came from identity, we initially thought this would be easy. But when we tried to implement it using the conventional approaches, we realized that the necessary infrastructure had not really been created for AI agents. We spoke with people at OpenAI, Anthropic, and LangChain, and there was no established answer for how to do it correctly.

After several months, we got it working. The surprising part was that, when we demonstrated the product, people were less interested in the original SRE agent than in the infrastructure underneath it. They would ask: “How did the agent log into Datadog on my behalf while still acting as an agent?” That was when we realized we had built something more important than the original product.

Peter Thum: Was the decision to pivot obvious internally, or did it take a long debate?

Alex Salazar: I had the benefit of having founded a company before. My previous company was acquired by Okta, which is how I ended up there. Once you have been through the startup journey, it becomes easier to recognize when something is not working.

With the original agent, people simply were not excited enough. We would ask prospective customers directly whether they would pay $100,000 for it, and the answer was no. We made the decision within four or five months that the product was not going to work. We were fortunate that the thing we should pivot toward was already sitting directly in front of us.

Kim Isenberg: For someone who understands technology but is not deeply immersed in agent infrastructure, what is the simplest explanation of Arcade?

Alex Salazar: We make it easy to connect an AI agent to business systems: email, calendars, documents, GitHub, ticketing systems, CRMs, ERPs, and so on.

The crucial part is that we help establish, check, and prove that a particular agent, acting on behalf of a particular user, is allowed to perform a particular action on a particular resource. For example: Claude, acting on behalf of Alex, may update this CRM record. Or Microsoft 365 Copilot, acting on behalf of Peter, may send an email in Outlook.

Peter Thum: The permissioning layer sounds extremely complex. Every application exposes different permissions, and users do not want to study a technical manual every time an agent needs access. How do you make that manageable?

Alex Salazar: That is exactly the challenge. Traditional identity systems focused heavily on authentication: Who is the user? Can they log in? With agents, identifying the user or the agent is relatively straightforward. The hard question is what they are allowed to do.

That is authorization — or access control, permissions, and entitlements. Historically, identity companies often avoided that area because it is extremely difficult. Implementations can become highly bespoke and may require significant professional services.

With agents, however, authorization becomes the central problem because you cannot trust the agent to enforce its own policies. You cannot simply hand an agent an access-control list and assume it will always follow it. Enforcement has to occur outside the agent.

The complexity also differs from one system to another. Gmail and Outlook are both email systems, but their permission models are completely different. AWS, Google Cloud, and Azure serve similar purposes, yet each has a radically different permissioning architecture.

That means we have to understand the underlying systems in detail. Our MCP servers need to be permission-aware, enterprise-ready, and optimized for agents. We build first-party integrations for systems such as Gmail, Outlook, Slack, and GitHub because the runtime itself has to understand the permissions it is enforcing.

The other side is understanding intention. A user does not tell an agent which API endpoint to call. They say: “Find all emails from Kim and archive them.” We have to map that human intention onto the detailed permission structures of the downstream system.

We are now taking that further with what we call “missions,” which is in early access. The goal is to anticipate what a user is likely to ask an agent to do and prepare the necessary permissions before the agent reaches that step, without simply granting broad access in advance.

Across product, ops, and CX teams, a new kind of role is taking shape: the person responsible for making AI actually work, day to day. In this roundtable, three people living this shift share what it's really like: Simone Santiago Broad (Yoco), Yelva Espinoza (Zumba Fitness), and Fin's Dave Lynch. You'll hear how they carved out these roles, what the job looks like across industries, the skills they'd hire for, and the challenges they're tackling right now.

Watch the full conversation on demand.

Watch now

Kim Isenberg: What are the most common mistakes companies make when they try to solve this problem today?

Alex Salazar: We generally see three failure patterns.

The first is giving the agent its own identity — often called a non-human identity, machine identity, or service account — and assigning permissions directly to it.

Imagine an agent that analyzes compensation data in Workday. The agent may be able to read the CEO’s compensation. But what happens when an intern can access the same agent? The intern must not inherit the agent’s ability to see the CEO’s compensation.

Companies often respond by reducing the agent’s permissions to the lowest common denominator. Now the agent is safe for the intern, but it is no longer useful for the CEO or the head of HR. That destroys much of the return on investment.

The second pattern is giving the agent the user’s full identity. This creates a smooth experience because the agent can do everything the user can do, and it cannot access anything the user could not already access. But it is wildly unsafe. If I can delete files, emails, database tables, or production deployments, the agent can potentially do the same. CISOs and CIOs at large companies are increasingly shutting down these deployments because the blast radius is too large.

The correct model is the intersection of the agent’s permissions and the user’s permissions. Both must be authorized for the action.

If the agent may read compensation data but the intern may not, the request fails. If the user has super-admin access to production but the agent is restricted to reading server data, then the agent may only read server data.

The third failure pattern is implementing that intersection but asking for every possible permission upfront. That violates the principle of least privilege. An agent should receive only the access it needs at that moment. If it hallucinates or behaves unexpectedly, the damage it can cause is therefore constrained.

Peter Thum: Is there a middle ground where the agent can say, “I know I do not currently have this permission, but I need it to complete the task,” and request a temporary escalation?

Alex Salazar: That is where the research is heading. Agents are very good at pursuing a user’s goal, sometimes to an uncomfortable degree. The challenge is that the party requesting more privileges is itself untrusted.

An agent may explain that it needs additional access to complete the task, but how do you determine whether that request is legitimate? You may allow it to read an inbox, but reorganizing folders, deleting emails, or deleting contacts is a different privilege level.

The research frontier is determining when escalation is justified, granting it only when necessary, and doing all of this in a way that remains fast, accurate, and almost invisible to the employee. Most users do not understand — and do not want to understand — privilege escalation or governance workflows. If the experience becomes too burdensome, they will stop using the system.

Kim Isenberg: In one sentence, what is the difference between an agent that can call tools and an agent that can safely act inside a company?

Alex Salazar: An enterprise-ready agent follows the organization’s rules, and the organization can prove through audit logs that those rules were followed.

Every company above a certain size has rules governing who can access which systems and what they can do inside them. The larger the company, the more complex those rules become. If an agent cannot follow those rules — or if the company cannot demonstrate that it did — the agent will not be allowed into the organization.

Kim Isenberg: For a company running a typical stack — Gmail, Slack, GitHub, and internal systems — what has to exist before an agent can act on behalf of a user?

Alex Salazar: The foundational requirement is APIs. There is a lot of confusion about the difference between MCP and APIs, but they are not the same thing.

An API is a service-level contract. It describes how a system such as Slack or Gmail works and which operations are available. A well-designed MCP server is more intention-based. It is closer to what the user wants to accomplish.

Take a simple email request: “Reply to Kim and tell him I am five minutes late.” The Gmail API does not expose a single “reply to this person” endpoint. The agent may have to find the message, retrieve and unpack the MIME content, construct the reply correctly, repackage it, and send it.

An MCP server can expose “reply” as a higher-level tool. The model no longer has to write and coordinate all of that logic on the fly. That makes the process faster, cheaper, and less error-prone.

So MCP depends on APIs, but it is not merely another API. It provides a standardized, agent-oriented way to express and execute intentions. The second requirement is an agent that supports MCP, which has rapidly become the common standard for tool connectivity.

For a large organization, there is still significant work involved in connecting internal systems and governance rules. But if the systems expose APIs and the agent supports a recent MCP implementation, the basic technical foundation is in place.

Kim Isenberg: How should we distinguish identity for humans, identity for applications, and identity for agents?

Alex Salazar: A common metaphor is that an agent is like an employee. That can be useful when thinking about how an agent should behave, but technically it breaks down.

An agent is really an application — a highly capable, non-deterministic software workflow, but still a software workflow. Treating it as a separate user or peer identity leads people toward service accounts and non-human identities, which create serious problems when the agent acts on behalf of many different users.

Existing software systems generally do not support one user delegating their complete identity to another user. You cannot simply say, “Peter may control Kim’s account for the next hour.” The existing standards and security models were not built around that construct.

What makes agents different from traditional applications is that traditional software is deterministic. It follows the code you wrote, unless there is a bug. An agent does not behave with that level of predictability. It cannot be trusted to enforce its own rules.

That leads to one of our core conclusions: policy enforcement, access-control enforcement, and governance cannot live inside the agent. They have to live outside it.

The most natural enforcement point is the action layer — the moment the agent attempts to do something in another system. The agent can hallucinate whatever it wants. The security-relevant moment is when it tries to send an email, alter a record, delete a file, or change a production environment.

MCP has created a natural place to apply that enforcement because the requests pass through a common interaction layer.

Kim Isenberg: Some people might say that model guardrails are supposed to prevent this kind of behavior. Why are they not enough?

Alex Salazar: Guardrails and access control solve different problems.

Guardrails are primarily about alignment: shaping what the model should or should not do. Access control is about governance: defining what the system is technically able to do, regardless of its intentions.

Think about raising a child. You teach your children ethics, responsibility, and good judgment. That does not mean you give them unrestricted access to your bank account. Even a well-behaved person can make a mistake.

Organizations already operate this way with employees. Trusted employees still do not receive super-admin access to every system. People can make errors, be socially engineered, or have their credentials compromised. The goal is to limit the damage by ensuring that nobody has access they do not need.

The same principle applies to agents. Good guardrails are important, but they do not replace governance and permission enforcement.

Peter Thum: You have to understand Gmail, Outlook, Slack, GitHub, cloud platforms, and countless internal systems. How can a startup cover that surface area without becoming infinitely large?

Alex Salazar: That is a real strategic trap. You cannot build and maintain everything yourself.

We apply an 80/20 approach. For the most common enterprise systems — Gmail, Outlook, Slack, GitHub, and others — we build best-in-class first-party integrations that are permission-aware, governance-aware, and optimized for LLMs.

We also created Toolbench, where MCP servers are evaluated against the quality standards we use internally. The current ecosystem is still very early, and many MCP servers are not yet enterprise-grade. By publishing the rubric and the results, we hope to show developers what “good” looks like and raise the quality of the entire ecosystem.

For the long tail, we provide an authoring framework and tooling that customers can use themselves. Even a platform such as Salesforce is implemented differently in every company. A generic Salesforce MCP server may not match a company’s custom objects, workflows, and permission structures.

The same is true for SAP and internal systems at banks or large industrial companies. Those systems may be completely unique. We make it easier for customers to build and own those integrations themselves.

Over time, we also expect an ecosystem of independent developers and consultants to build specialized MCP solutions and distribute them through platforms like ours. Monetization and revenue sharing are areas we are actively exploring, although custom internal integrations at large enterprises are usually too specific to become broadly reusable products.

Kim Isenberg: What does an MCP gateway actually do in practice, beyond connecting a model to a tool? And does MCP create a larger attack surface?

Alex Salazar: At the simplest level, a protocol is an agreement about how two systems communicate. The web works because browsers and websites speak HTTP. For agents, MCP is becoming that common language.

The protocol is evolving rapidly because the industry is still learning what an agent needs to request and what a downstream system needs to expose. In that sense, it resembles the early evolution of HTTP.

And yes, it creates new attack surfaces. We are already seeing new classes of identity and authorization vulnerabilities. That is not unusual for a new platform shift. The same thing happened with the web and with cloud computing. The ecosystem now has to discover those vulnerabilities, establish standards, and build the infrastructure to mitigate them.

Kim Isenberg: How granular do permissions need to become — application level, user level, action level, data level? And how do you prevent an agent from chaining several small permissions into a much larger capability?

Alex Salazar: In a perfect world, permissions would be as granular as possible. In practice, granularity costs time, money, and expertise. The realistic answer is that permissions will be as granular as the underlying systems expose and as the use case requires.

The more granular permissions become, the worse the user experience can become. Anyone who has used a coding agent and repeatedly clicked “approve” has experienced this. Eventually, users stop reading and approve everything.

The goal is therefore to preserve detailed controls without presenting all of that complexity to the user.

Least privilege is also what prevents permission chaining from becoming dangerous. The agent should receive only the access it needs for the current action. Every new request should be reauthorized.

In Arcade’s architecture, every interaction between the agent and an external system passes through us. The agent never receives the underlying keys. We act as a broker. On every request, we can check the user, the agent, the action, the resource, and the organization’s governance rules. That limits the agent’s ability to accumulate power or go rogue through a sequence of tool calls.

Peter Thum: Arcade has said it is deploying across Fortune 500 companies. Without naming customers, what are you learning from real enterprise rollouts?

Alex Salazar: The deployments are surprisingly horizontal. We work with banks, industrial companies, sports organizations, and technology companies, but the underlying problem looks almost identical across industries.

Every large organization feels pressure to establish an AI-agent strategy quickly. They can see the potential productivity gains, and they know their competitors are moving. Nobody wants to become the Blockbuster of this technology cycle.

At the same time, these companies have valuable businesses to protect. They cannot simply ignore security and governance. They want to move fast without exposing the company to a catastrophic breach or an avoidable operational mistake.

One of the most interesting findings is that we are not seeing as many fully autonomous agents as the public discussion might suggest. The majority of deployments involve a human operator working directly with an agent.

That is also where the strongest productivity gains appear. The “cyborg” model — human plus agent — outperforms either the human or the agent working alone. The breakthrough is that, for the first time, a user can state an intention in natural language and receive an outcome.

I do not think the future is simply autonomous agents replacing human-operated systems. It is likely to be an “and,” not an “or.”

Alex Salazar: One effect we already see in our own company is that the browser is becoming less central.

We have an internal rule: if someone has to open a browser to complete a routine workflow, they should file an engineering ticket. The goal is to force ourselves to experience the future we believe is coming — a world in which people express an intention and agents coordinate the underlying systems.

That does not mean visual interfaces disappear. Humans are visual, and pure text is not always ergonomic. But the old model of manually navigating through applications and clicking through menus is likely to change significantly.

MCP UIs and MCP apps may be early steps toward a new interface model, but the final form is still unclear.

Kim Isenberg: Arcade has said it helped author the MCP authorization specification. What part of that work is public, and where is the line between contributing to an open standard and owning it?

Alex Salazar: We do not own it. MCP is an open standard.

There are two major authorization questions. The first is how an agent accesses the MCP server. The second is how the system decides, action by action, what the agent may do on behalf of a particular user — for example, whether it may read, send, or delete.

Arcade has contributed to that broader authorization work, including tool-level authorization and secure out-of-band authorization flows. Nate Barbettini and Wils Dawson, early Arcade employees who previously worked at Okta, authored the proposal that became MCP’s URL Mode Elicitation specification, with input from the wider ecosystem.

The formal specification language may be technical, but the practical idea is straightforward: authorization must be evaluated at the tool and action level, and sensitive permissions should be granted through a secure user interaction rather than exposed to the model.

Peter Thum: Are highly regulated industries such as finance, insurance, and healthcare naturally the strongest market for this infrastructure?

Alex Salazar: The more sensitive the operation, the more urgent the need. But you do not need to be handling medical records or private-wealth data for this to become a serious issue.

Something as basic as preventing Peter from reading my private Slack messages requires the same underlying capability: Can this agent, acting on behalf of this user, perform this action on this resource?

Email, HR systems, compensation data, and internal documents are sensitive in almost every industry. The more useful segmentation is not how regulated a company is, but how AI-forward it is.

The organizations feeling this problem most acutely are the ones moving fastest and putting agents into real workflows.

Peter Thum: When an agent makes a serious mistake, who ultimately owns the failure: the user, the customer, the model provider, or the team that deployed it?

Alex Salazar: In practice, responsibility usually falls on the team that built and deployed the agent.

The security team is often the group warning about the risks. The agent itself is not a legal person, so blaming it is meaningless. The end user may have had no visibility into the chain of actions the agent performed behind the scenes. Unless the user acted maliciously, they are unlikely to understand enough to carry the responsibility.

That leaves the team that designed the system, selected the controls, and put it into production. Humans still exist, unfortunately, to absorb the blame.

Peter Thum: What would you tell students entering careers that could be significantly reshaped by AI? Should they aim to become expert intermediaries who work alongside agents?

Alex Salazar: I graduated at the peak of the dot-com crash. At the time, there was a similar fear that the internet was destroying industries and jobs. I had friends from top computer-science programs waiting tables because they could not find work.

Yet many of the companies that later came to dominate the S&P 500 were built by that same generation. Today’s graduates may face a difficult transition, but because they are AI-native, they may also be the people who build the next generation of major companies.

My 15-year-old daughter already treats older interfaces as unnatural. If she sees me typing a response on my phone, she takes it from me, presses the transcription button, dictates the message, and calls me a dinosaur.

Every major technological shift reorganizes work. The meaning of “software developer” in 2026, 2027, and 2028 will evolve. But the people at greatest risk may not be the youngest workers. It may be mid-career professionals who are unwilling to invest the time and energy required to change how they work.

There are still many people who default to Google for every question or write every email manually. The gap between those users and people who have fully integrated AI into their workflows is becoming significant.

Kim Isenberg: If MCP becomes the common interface between models and tools, which parts of agent infrastructure remain unsolved?

Alex Salazar: A great deal. It is still extremely early.

The industry is making rapid progress on how agents communicate with external systems and on the intelligence of the underlying models. But several major questions remain open.

How does an agent know personal or organizational context without exposing that information inappropriately? How will agents communicate with other agents? Is A2A the right protocol, and what will the important use cases be? How do permissions propagate safely across chains of agents that hand work to one another?

We also do not know what the right user interface will be. Text has dominated so far, but typing is not always the most natural way to work. We moved away from command-line interfaces for many tasks because people are visual. The future is unlikely to be a return to point-and-click software, but the replacement is not yet fully visible.

Finally, the boundaries remain fuzzy between a general-purpose agent such as ChatGPT or Claude, a specialized agent application, an MCP server, and an agent-to-agent layer. The industry will have to discover where each of those layers begins and ends.

Peter Thum: If Arcade hits a home run over the next year, what does that look like?

Alex Salazar: The future of AI is unusually opaque, and it moves too quickly for conservative bets. Internally, we try to take many ambitious shots rather than optimizing for incremental wins. In AI, a cautious product roadmap can become obsolete before the product ships.

We also force ourselves to operate as though we are already 24 months into the future. We use agents aggressively inside the company because we want to experience emerging workflows before our customers do.

The models will improve. People routinely underestimate the rate of progress because humans are bad at thinking exponentially. Every year, we try to predict where model performance will be in 12 or 24 months, and every year we still underestimate it.

So when someone says, “The model cannot do that,” our assumption is often: maybe not today, but it probably will be able to do it within 24 months. That belief shapes which problems we choose to solve.

Kim Isenberg: What is one assumption about enterprise agents that you expect the industry to abandon over the next 12 months?

Alex Salazar: The biggest one is the idea that service accounts or non-human identities are a sufficient identity model for agents.

Companies adopted service accounts because they were the only available way to get many agent workflows running. Now they are discovering the limitations: the permissions do not map cleanly to the user, privilege boundaries collapse, and the model does not scale safely across an organization.

The agent has to remain connected to the identity and permissions of the user on whose behalf it is acting. Otherwise, enterprise deployment will continue to break down.

Kim Isenberg: Alex, where can people follow what you and Arcade are building?

Alex Salazar: The best places are arcade.dev, X, LinkedIn, and the Arcade YouTube channel.

Kim Isenberg: Alex, thank you for joining us.

Peter Thum: Thank you, Alex. You have demonstrated that agent permissioning may be easier to explain than a baseball analogy to a European.

About the interviewers: Kim Isenberg is Editor-in-Chief and Co-founder of Superintelligence. Peter Thum is Co-founder of Superintelligence and co-host of the company’s interview series.

92% of VCs use AI to find companies. 58% of buyers start there too. If you're not showing up in AI answers, you're invisible before the conversation even starts. Join HubSpot for Startups, Anthropic, and Marketing Against the Grain on July 16 (11am ET) for a live AEO teardown. Real startup. Real recs. Register and unlock the free Startup Visibility Bundle.

Register Now

The sharpest point Salazar makes is also the least technical one. Agents do not fail in production because the model is wrong. They fail because nobody can prove that a particular agent, acting for a particular user, was allowed to perform a particular action on a particular resource. That reframes the whole enterprise AI question.

The industry spends its attention on benchmark scores while the thing actually blocking deployment is an audit log. His three failure patterns are worth memorising, because almost every company currently piloting agents is sitting in one of them: the service account that has to be dumbed down until it is useless, the borrowed user identity with a blast radius nobody has measured, and the correct intersection model implemented so eagerly that it asks for every permission upfront.

The second idea worth carrying out of this conversation is where enforcement has to live. A non-deterministic system cannot be trusted to police itself, so the policy cannot sit inside the agent. It has to sit at the action layer, the moment the agent tries to send, write, or delete something in another system, and MCP has quietly created a common chokepoint where that check can be applied. Salazar's answer on blame is the honest coda. The agent is not a legal person, the user never saw the chain of calls it made, so responsibility lands on whoever designed and shipped the thing. Our thanks to Alex Salazar and the Arcade team for the exclusive.

Alex Salazar is Co-founder and CEO of Arcade, which he started in 2024 with CTO Sam Partee, previously an engineer at Redis. He has spent most of his career in identity. He co-founded Stormpath, the first authentication API built for developers, and stayed on after Okta acquired it, eventually running Okta's developer products, a line that accounted for roughly a quarter of the company's bookings and a network of more than 5,000 auth integrations. He holds a computer science degree from Georgia Tech and an MBA from Stanford. Arcade itself began as an agent for site reliability engineering and pivoted within five months, once customers made it clear that the authorization plumbing underneath was the more valuable product.

Arcade builds the action and authorization layer between AI agents and the systems they operate on. It brokers every call, so the agent never holds the underlying credentials and each request can be checked against the user, the agent, the action, the resource, and the organisation's own governance rules. The company ships first-party, permission-aware MCP servers for the systems most enterprises actually run on, including Gmail, Outlook, Slack and GitHub, alongside an authoring framework for the long tail of internal systems, and it publishes Toolbench, a public evaluation of how well third-party MCP servers hold up against enterprise standards. Arcade also co-authored the URL Mode Elicitation proposal (SEP-1036) that has been accepted into the Model Context Protocol specification.

In June 2026 the company raised a $60 million Series A led by SYN Ventures, with strategic investment from Morgan Stanley and Wipro. That takes total funding to roughly $72 million, after a $12 million seed in March 2025 led by Laude Ventures, the fund founded by Perplexity and Databricks co-founder Andy Konwinski. Arcade says its runtime now executes agent actions in production across Fortune 500 customers, and it exposes more than 8,000 MCP tools.

Sources:
🔗 Arcade, official Series A announcement (June 2026): https://www.arcade.dev/blog/arcade-series-a
🔗 SiliconANGLE, "AI agent authorization startup Arcade nabs $60M investment": https://siliconangle.com/2026/06/15/ai-agent-authorization-startup-arcade-nabs-60m-investment/
🔗 Model Context Protocol, SEP-1036: URL Mode Elicitation for secure out-of-band interactions: https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1036
🔗 Arcade Toolbench, the public MCP server evaluations: https://toolbench.arcade.dev/
🔗 TechCrunch, Arcade's $12M seed led by Laude Ventures: https://techcrunch.com/2025/03/18/arcade-raises-12m-from-perplexity-co-founders-new-fund-to-make-ai-agents-less-awful/