No Back Door Through the Chat: Carrying App Entitlements into AI Tool Calls

Key takeaways

• Adding an MCP server to a paid desktop app opens a second way in. If the plan check lives only in the app's screens, the AI route skips it.
• In KwaFlux, AI tool calls pass the same sign-in and plan check as clicks, in the same place: the app's control plane, not the MCP script.
• The worker that runs the job checks again, by verifying a lease signed with Ed25519 before it starts paid work.
• Resuming or retrying a task goes through the checks again at that moment, so a lapsed plan or a switched-off setting can't be kept alive by retrying.

When we added an MCP server to KwaFlux, one rule came first: an AI assistant should be able to do exactly what you can do in the app, not more and not less. So the account check that guards a feature applies to tool calls the same way it applies to clicks.

It also has to hold when the assistant retries a task later, after your plan or your settings may have changed.

In this guide, you'll learn where a second path to paid features usually appears, how KwaFlux keeps one check for both paths, what the worker's signed lease adds, and why every retry is checked again.

Contents

1. What is an entitlement check?
2. Where the back door usually appears
3. One check, in the app
4. A second check at the worker
5. Resume and retry go through the checks again
6. What's free over MCP
7. What this design is and isn't for
8. FAQ

What is an entitlement check?

An entitlement check is the step where software confirms that the signed-in account has the plan or license a feature requires, before it lets the feature run.

In KwaFlux, the features that write files, which are exports (including AI enhancement), conversions, file repairs, and downloads from a link, need sign-in and a plan. Everything else, such as browsing, importing, previews, and diagnosing a file, works without an account.

Where the back door usually appears

Desktop apps often check the plan in the user interface: a button is disabled, or clicking it shows an upgrade screen. That works until a second caller arrives.

An MCP server is a second caller. If it sends jobs straight to the engine, or calls an internal function that the button used to guard, the UI check doesn't run. The MCP specification puts access control on the server side for this reason: servers "MUST" validate all tool inputs and "implement proper access controls." A check that lives in the button doesn't count.

One check, in the app

KwaFlux puts the check where every request has to pass: the control plane inside the running app. The MCP script doesn't decide anything about plans. It forwards a typed request, and the app answers.

If you're not signed in, or your plan doesn't cover the feature, the assistant gets a structured error saying so, and it can tell you to sign in. It can't work around it, because there's nothing else to call. For how the layers fit together, see why AI agents shouldn't click the screen.

A second check at the worker

The app's check decides whether a job may be queued. The worker, the separate process that actually runs the engine, makes its own check before it starts paid work: it verifies a lease for the task, signed with Ed25519.

A signature check in a different process means the decision doesn't rest on one place. A job that reached the worker any other way, without a valid signed lease, doesn't run its paid features.

Ed25519 is the Edwards-curve signature scheme specified in RFC 8032. It uses small keys and signatures (32-byte public keys and 64-byte signatures for Ed25519), and verification is fast, which suits a check made for every task.

Sidenote: We're deliberately not describing what a lease contains or how long it lasts. The point of the design is that the worker can verify it without trusting whoever handed it the job.

Resume and retry go through the checks again

Retries are the subtle part. A task that was allowed when it was queued may not be allowed when it's resumed an hour later. KwaFlux treats resume and retry as new decisions:

• The plan is checked again. If your plan has ended since the task was queued, resuming or retrying a paid task fails the check, just as a new request would.
• The download setting is checked again. If you've turned agent downloads off since an assistant queued one, retrying it is refused. See why an AI can't approve downloads for you.
• Ownership is checked again. An assistant can only resume or retry tasks it submitted.

The alternative is a task that, once approved, can be retried indefinitely on the strength of a decision that no longer holds. Checking at the moment of action closes that gap.

What's free over MCP

The free part of KwaFlux stays free over MCP. Without signing in, an assistant can:

• check whether KwaFlux is running and signed in;
• list tasks and read their status;
• diagnose a damaged file to see whether it can be repaired;
• pause or cancel its own tasks.

Free 1-, 3-, and 5-second previews stay in the app; the assistant doesn't render them.

What this design is and isn't for

This design keeps the rules the same on both paths. An AI assistant doesn't unlock anything, and it doesn't lose anything you're entitled to. Every request goes through the same check, and every task the assistant starts appears in the app's task list, tagged with the assistant that submitted it.

It isn't a substitute for the protection of the channel itself, which keeps other accounts and other computers from talking to KwaFlux at all. That's in securing the local channel.

Final thoughts

Adding an AI interface to a paid app is a chance to find out where your checks really live. KwaFlux keeps one check in the app's control plane for clicks and tool calls alike, has the worker verify a signed lease before paid work, and checks again whenever a task is resumed or retried. The assistant gets the same KwaFlux you do.

The same KwaFlux, from your app or your assistant

KwaFlux's local MCP server lets Codex, Claude, Cursor, and other MCP apps start the same jobs you can start in the app, under the same rules. AI processing runs locally on your GPU — media files are not uploaded for processing. It runs on Windows 10 (64-bit, version 1809 or later), Windows 11, and macOS 12 or newer on Apple Silicon. Importing files and exploring the app need no account. Signing in with an active paid plan is required only to export, convert, repair a file, or download a file from a link.

Download KwaFlux · See plans