Veto

Building control infrastructure for the agentic era. Defining what autonomous systems can access, execute and delegate.

[Veto @vetoprotocol]

Veto dApp beta is now live.

Your AI agents can work for you without unrestricted access.

Register an agent, connect supported services and set policies that define what it’s allowed to do. Supported requests through Veto are checked against your rules.

This beta is an opportunity to explore the platform and share feedback as we improve the experience and expand integrations.

Start with one agent. One workflow. Clear boundaries.

Open the dapp: https://t.co/XtWc9Vmiuq

Delegate intelligence. Retain authority.

[Veto @vetoprotocol]

This article gets into why a capable agent shouldn’t automatically have unrestricted access.

Give it a read, what would you let your agent do on its own and what would still need your approval?

Happy to answer questions.

[Veto @vetoprotocol]

https://t.co/5tur2aqWIS

[Veto @vetoprotocol]

Claude Code Connected Through Veto

You shouldn’t need to switch AI assistants to put boundaries around their access.

In this walkthrough, we connect the standard Claude Code client to Veto through MCP without a custom agent or Veto-specific client code.

Then we ask a simple question:
“List my Google Drive content using Veto.”

Here’s what happens:

• An unauthenticated request is refused.
• After signing in, the request is checked against the configured permissions.
• Claude receives a listing of 50 files and folders not their contents.
• The decision appears in Veto’s activity history for review.

Listing files doesn’t grant permission to open them. Reading a file requires another request and another permission check.

That’s the practical value: use your assistant for useful work while keeping access tied to specific rules. These controls apply to supported requests routed through Veto.

Watch the walkthrough below.

Explore the beta: https://t.co/XtWc9VlKES

[Veto @vetoprotocol]

Our recent walkthroughs have shown agents finding files, checking emails and looking at calendars.

Different tasks but the idea behind them is the same, agents need access to be useful but that access needs boundaries.

As we hand more work over to AI, we need a clear way to decide what each agent can access which actions need approval and when that access should stop.

That’s what we’re building $VETO for a permission layer for agentic workflows.

Today, the beta applies these controls to supported requests that go through Veto. If an AI tool uses a separate connection that activity sits outside Veto’s control.

We’re now working on supporting more services and bringing more everyday workflows into Veto. As that grows, the goal stays simple is to give agents the access they need without giving up control.

Clear permissions. Approvals when needed. Access you can revoke. Activity you can review.

We’ll share more integrations and walkthroughs as they roll out.

Explore the beta: https://t.co/XtWc9VlKES

[Veto @vetoprotocol]

A Veto Walkthrough - Your Calendar Within Your Rules!

“List my upcoming events using the Veto tool.”

In this demo, the agent checks the tool’s requirements, chooses a 30-day window and returns the upcoming event with its title, times, location and attendee count.

The listing doesn’t include the event description or private notes. Reading an individual event is a separate request with its own authorization check.

A few important boundaries behind the result:

• The calendar is determined by the signed-in user’s session not an account the agent chooses.
• Each calendar-list request is limited to a maximum 90-day window.
• Every call is checked individually and recorded in the audit timeline.

The walkthrough also shows the setup: attach the calendar resource and configure the required policy. Connecting an agent alone doesn’t grant access.

Useful help with your schedule without permission to create, change or cancel events.

Try the beta: https://t.co/XtWc9VlKES

[Veto @vetoprotocol]

The first refusal is important that’s Veto doing its job and enforcing the boundary not a connection issue. The request only goes through once the right access is set.

Give the walkthrough a watch and if you’ve got any questions, drop them below.

[Veto @vetoprotocol]

In this demo a DeepSeek-powered agent connects to Veto and is asked to list five recent emails.

The first request is denied.

Nothing is broken. The agent is connected and can see the tool but it doesn’t have permission to use it.

We then configure the relevant policies and attach the required resource. On the next attempt, the request passes Veto’s checks and returns five email headers: sender, subject and date.

Not the message bodies. Reading an individual email requires a separate authorization check.

That’s what this walkthrough demonstrates: Access is checked when a request is made not granted indefinitely when an agent connects. Each recorded decision can also be reviewed in the audit timeline.

Your agent can do the work. You define the boundaries.

Try the beta: https://t.co/XtWc9VlKES

[Veto @vetoprotocol]

Dev Supply Locked for One Month 🔒

We’ve locked all dev supply for one month.

Verify the lock: https://t.co/mdRiSCEUSL

The lock details are public so everyone can check the amount and unlock schedule directly.

Meanwhile we’re focused on improving the Veto beta expanding supported services and acting on your feedback.

[Veto @vetoprotocol]

Give this a read if you’re curious about what happens behind an AI agent’s response what it requested, what was allowed and what got blocked.

If you have any questions about how this works in Veto, drop them below.

[Veto @vetoprotocol]

https://t.co/o0YQeRLzMO

[Veto @vetoprotocol]

The important part isn’t just that the agent got the result it’s that Veto checked whether it was allowed to access it first.

$VETO gives you a control layer between your AI agents and connected services. Instead of giving an agent open-ended access, every supported request is checked against the permissions you set.

In this walkthrough the agent can list files but it can’t write or delete them. Every decision is recorded too so you can see exactly what was requested and what Veto allowed.

Your agents can get work done without giving up control. What workflow should we show next?

[Veto @vetoprotocol]

A Working Agent - From Request to Result

The earlier walkthroughs showed the setup. This one shows an agent using it.

The user asks: “List my Google Drive content using the Veto tool.”

The assistant calls the tool and returns a live listing of files and folders. No file IDs, paths or API keys typed into the request just a task in plain English.

Behind that interaction, Veto checks the agent’s identity, session status, permissions and access to the requested resource. The decision is recorded in the audit trail.

The connection shown is read-only: Reading files is permitted, writing and deleting are not.

An important detail at the start: the dashboard shows 18 decisions, with 11 blocked or held for approval. This walkthrough follows an allowed request not a connection where everything gets through.

That’s the goal: Let agents do useful work within boundaries you control.

Try the beta: https://t.co/XtWc9VlKES

Delegate intelligence. Retain authority.

[Veto @vetoprotocol]

Presence, Activity & Alerts - A Veto Walkthrough

You shouldn’t have to keep changing your agent’s permissions every time you step away.

$VETO lets you change your presence while keeping your existing permission rules in place:

• Active: Low-risk requests can continue within the permissions you’ve already set.
• Away: Sensitive reads and supported write actions need your approval.
• Locked: Protected actions through Veto are blocked.

Being Active doesn’t give your agent any extra access. And if your presence signal expires, Veto automatically switches you to Away.

This walkthrough also covers the emergency lock, activity history with integrity checks and configurable alerts that can be sent directly to your own endpoint.

So you don’t need to sit there watching the dashboard.

See what happened. Decide what you want to be alerted about. Lock things down whenever you need to.

Try the beta: https://t.co/XtWc9VlKES

[Veto @vetoprotocol]

What’s one task you’d delegate to an AI agent and one thing you’d never let it access?

We’d love to hear real examples as we improve the Veto beta.

[Veto @vetoprotocol]

https://t.co/AW65QzrXiK

[Veto @vetoprotocol]

Before the Veto dapp goes live we’re sharing our GitHub.

Explore the code behind the project and see how we’re building policy-based controls for AI agents.

Developers: questions, feedback and contributions are welcome. If you spot a potential security issue, please report it privately.

GitHub: https://t.co/n3PXK6p6i3

Delegate intelligence. Retain authority.

[Veto @vetoprotocol]

Veto dapp goes live in 2 hours.

After 24 hours of hands-on product testing. We’re excited to announce that the Veto dapp goes live in 2 hours.

Register your AI agents, connect supported services and set clear boundaries for what they can access through Veto.

We’ll share the official access link and a setup walkthrough at launch.

Delegate intelligence. Retain authority.

[Veto @vetoprotocol]

Connecting Google - A Quick Walkthrough

Connecting your services to an AI agent shouldn’t mean giving it access to everything.

With $VETO you connect each service separately like Drive, Gmail or Calendar. Access to one doesn’t automatically give access to the others.

Current integrations are read-only. Your agent can’t send emails, edit or delete files, or make changes to your calendar.

From there, you set the boundaries. Veto’s policy controls define what the agent can access and which actions it’s allowed to perform. Every supported request routed through Veto is checked against those rules.

And when something changes, you stay in control. Update the permissions or revoke access when the agent’s work is done.

A connection makes access possible.Your policies decide what’s permitted.

[Veto @vetoprotocol]

Some decisions stay yours.

An agent can prepare an action without having permission to carry it out.

With approval rules, selected requests through Veto pause for a human decision before execution. That gives you a chance to review the proposed action before it affects a connected app.

A pending request is still pending. It isn’t permission.

stay tuned!