What Happens When You Connect an AI Agent to Your Preveo Account?

Connecting an agent to a service usually begins with a button or a command. The more useful question is what happens after you approve it.

Which account does the agent use? Can it see private projects? Does it receive your website login token? And where do you go when you want the connection to end?

Here's how Preveo's MCP connection is implemented, from browser sign-in to disconnecting an app.

The browser establishes whose account you're using

When an MCP client starts Preveo's OAuth flow, it opens a browser consent page. If you're already signed in on that Preveo frontend origin, it can use the existing session. Otherwise, you sign in and return to the pending request.

Check the account, requesting app, and return address shown on that page before approving. The app name is supplied by the requesting client, so the name alone shouldn't be treated as proof of who operates it.

Once you approve, the client completes the exchange and receives credentials for the MCP connection. Your ordinary web access token isn't handed to the client through this browser flow.

For Codex, the connection uses the server URL followed by an MCP login. The commands are in Preveo's setup reference; OpenAI's official MCP documentation covers the client-side authentication workflow.

The connection gets its own credentials

Preveo issues separate, opaque MCP access tokens. The implementation binds them to the configured issuer, MCP resource, registered client, and approved profile.

The authorization code is short-lived, single-use, and protected by S256 PKCE. That ties the code exchange to the client that initiated it, helping protect against someone else redeeming an intercepted code.

On the server, token and authorization-code values are stored as hashes rather than raw credentials.

This separation gives the connection a lifecycle of its own. It can be renewed or revoked without giving the agent a copy of the web token used for your normal browser session.

Preveo also supports a legacy manual-bearer configuration. If you're moving an existing client to browser sign-in, remove its explicitly configured bearer token first so it can use the intended OAuth credentials.

Account permissions still apply to the tools

The main MCP scope is currently named crafts:access. It allows the connection to use the supported MCP capabilities, subject to the account's existing permissions.

That includes more than reading: the tool surface includes creating review configuration, submitting capture jobs, uploading supported evidence, and sending access invitations when requested.

Signing in doesn't give the agent unrestricted access to every project. Entity and job operations check access using the validated profile. The profile identity comes from authentication rather than an arbitrary tool argument.

For example, a public macro doesn't make the results of a private thread readable. Access to that thread is checked before its saved results are returned.

It's also useful to distinguish service authorization from your instructions to the agent. The connection establishes what actions the account is allowed to perform. Your request, saved instructions, and client controls determine which actions it should take for the task.

Evidence tools return specific information

The MCP adapters define the fields they expose. Entity summaries can include names, descriptions, IDs, and links. Capture inspection can return media URLs, metadata, and requested bounded logs. Macro inspection can return saved findings and report links.

Full report HTML is excluded from the model-visible macro result by default and requires an explicit request.

Browser state, cookies, tokens, and raw internal job payloads aren't part of the ordinary entity inspection responses. That doesn't make every capture safe to share: the page image, recording, or log may itself contain information shown by your application.

Think about the content being captured as well as who can access the resulting review.

Refresh keeps an approved connection usable

The current implementation gives MCP access tokens a 15-minute lifetime. When offline_access is approved, refresh credentials can maintain the grant for up to 60 days without asking for consent on every routine refresh.

Refresh tokens rotate when used. Reusing an already consumed refresh token causes the associated grant to be revoked.

These are the implementation's current lifetimes and behavior. They explain why a connection can continue across coding sessions, while still having a defined expiration and revocation path.

Disconnect it from Connected apps

Open Connected apps from the dashboard account/settings menu, or go directly to Preveo's connection management page.

Disconnecting an app invalidates its connection tokens. Removing the account/profile also prevents continued access through that identity.

Revocation stops future authenticated use of the connection. It can't retract material a client already received, such as a downloaded screenshot, so choose captured content and recipients with that practical boundary in mind.

A good connection should be understandable from both ends: a clear sign-in and consent step when it begins, access checks while it works, and a visible way to end it when you're finished.