Skip to content
Anlyon
Esc
↑↓navigate↵open⌘Jpreview
On this page

Why Anlyon

Understand what can go wrong when your AI agent acts in your customers' accounts, what Anlyon prevents, and what you no longer have to build.

Anlyon lets your AI agent act in your users’ own accounts, safely.

Know what can go wrong

Your agent drafts an email in a demo and everyone is happy. Then it has to send that email from the user’s own Gmail, update a deal in their HubSpot, or post in their Slack. From that day, every mistake it makes lands on a real customer:

  • The wrong email goes out. A prompt injection in an inbound message tells the agent to forward the thread to someone else. It does, from your customer’s address.
  • A loop runs with no ceiling. A retry loop sends the same email again and again, or refunds an order twice.
  • A record disappears. The agent decides a contact is a duplicate and deletes it.
  • A key leaks. The user’s token sits in the process the model drives, and one instruction sends it somewhere else.

The customer doesn’t blame the model. They blame your product.

See what changes with Anlyon

Your agent names an action and passes input. Your server names the user. Anlyon checks that user’s limit and your rules, waits for the user’s yes when a step is risky, adds the user’s token, makes the call and returns a receipt.

Without Anlyon With Anlyon
A loop sends until someone notices. Each user has a limit, such as 20 emails a day, counted before the call. The next call is refused before it reaches the provider.
The agent sends whatever it decided. Risky steps wait for the user’s yes, in your app, on the exact request that will run.
The token lives where the model runs. The agent never holds a key. Anlyon adds the user’s token at the moment of the call.
A prompt could name a different user. Your server binds the user. The model’s tools have no user field.
You piece together what happened from logs. Every write returns a receipt with a grade, filed under the user. confirmed means a read-back of the provider’s own record matched.
Deleting a user means hunting through tables. One call erases the user: connections, limit counters and pending approvals.

Skip what you would otherwise build

Without Anlyon, an agent that acts for your users needs all of this before it does anything useful:

  • OAuth for each user. Consent screens, token storage, refresh, revocation, and a confirmation step so nobody can attach their account to someone else’s user.
  • A limit per user. A counter for each user and each rule, checked before the call, and released when a call is refused.
  • An approval backend. Store the exact request, show it to the right user, take their decision, and run that exact request and nothing else.
  • A record of every write. What ran, for whom, and what the provider says happened.
  • Erase. Remove everything about a user when they leave.

That is weeks of work, and none of it is your product. With Anlyon it is a few lines on your server: build a client with anlyon.forUser(userId), invoke actions by name, and send a user a connect link when a call says they haven’t connected yet.

Use your company’s own accounts too

The same calls work with your company’s own accounts, such as your Stripe or your GitHub. A call that names no user uses the workspace’s connection, counts against the environment’s limit, and is approved by your team. See Connected accounts.

Start

Was this page helpful?