Agents and keys

An agent gets a key, the same as a person. A key names the datasets it may see, each at one of three levels: Add rows only (it can post rows and read nothing), Read, or Read and write. We can also issue a key as masked (names, emails and the like replaced by stable stand-ins) or with an expiry; ask us. A masked key never reads a real value, on one dataset or on all of them, and that includes the raw copies we keep behind each source. A person or key making another key can give only dataset permissions it already holds; masked access can only be passed on masked. Every key can be revoked in a click on Settings, Agents.

Make a key

On Settings, Agents, an admin presses Make a key (while the AI policy is open; under inside-only, new keys for outside agents are off). In the panel that opens, give the key a name, choose its datasets and choose a level for each. The choices come from access you may give; masked access stays masked. The form describes the selection in words before you make it and shows the same description with the new key. Copy the key then, with Copy beside it: it is shown once, and closing the panel before it is copied asks first. The Keys table keeps its name, how it starts, what it may use in words, and when it was made; Revoke is the bin at the end of the row, shown when you point at the row (always on a phone), and it asks before it revokes. A key that signs in as a person in a group other than Everything, or that such a person made, says What their group, Reps, is given: that is all it reads, whatever it was made with, and it follows them when an admin moves them. What agents did is in Activity, under Outside a chat, with everything else that was done.

What each level lets a key do

Read sees a dataset's rows and what is built on them. It does not send anything out or start work: sending a sync, checking a destination, rebuilding the dataset's search and scanning it for personal details take read and write on that dataset, and so does seeing a webhook's address, since whoever has the address can post rows into the table. A reader sees that the webhook is there, where it lands and how many deliveries it took. Checking the whole company for problems takes an admin; Overscore does that on its own every few minutes anyway.

A key sees a dashboard or a saved query only when it can read the data behind it (Dashboards says how), and on Settings, Agents a key that may not make keys sees only its own line.

Sending your customers' details to an ad platform is an admin's decision: adding a Meta or Google Ads destination, taking one live, changing what its events say, and adding a sync to one take an admin, signed in or on their own laptop, never a key. A sync reads with the access of whoever set it up, whoever presses Send, and stops, with a card in your Inbox, when that key is revoked or that person leaves. A key sees only the destinations it could add or that send a dataset it reads, and a webhook's host, never its whole address. It is told only the metrics, and the problems the watcher holds, about data it reads.

Connecting Claude Code

claude mcp add --transport http overscore https://<you>.overscore.tech/mcp \
  --header "Authorization: Bearer ovs_…"

The agent gets the same doors as the app: the guide (read first), notes, table search, describe, query, insert, write a note, list tables; then the defined numbers (metric, define_metric, check_metric), what a dashboard shows, where a number came from and the rows behind it (dashboard_number, trace_number, rows_behind), the alerts (list_alerts, define_alert, run_alert), the scheduled emails (list_emails, write_email, preview_email, test_email), the accuracy tests (accuracy_tests, add_accuracy_test), your fields on a table's rows, destinations and syncs, Python models, and note_later for an improvement it spots but isn't making now. Every tool tells the agent's client whether it can change data, replace something, add work when repeated, or reach an outside service. The query tool can write when given a dataset; do not retry an insert or a build just because the connection ended before its answer arrived. Clients use these hints to decide when to ask you, but the key's permissions are always checked by Overscore. Its standing instruction is the same numbers guide the in-app assistant follows: ask the metric, filter it rather than clone it, define one if people will ask again, never work a number out by hand when a metric exists. The skills (read_skill) carry the steps for each kind of job.

When something broke or a number moved

Claude Code can do the looking the app does before it tells you, with its own AI and none of the app's. Five tools do it.

• inbox_cards lists the cards waiting in your Inbox as you see them there, each with what was found, the fix it offers and what an alert looked into. It never hands back a key or an address.
• run_log reads any run's steps and the end of its log, with the source's own keys taken out.
• freshness says how fresh each source and model is, the ones behind first.
• look_into_alert looks into an alert the way the app does before it tells you, by code, and hands back what it found.
• press_card presses a card's button, once, and only from your own laptop (ovs login). A key from Settings, Agents is refused, and a new key never goes through it.

At a terminal, ovs inbox and ovs runs --log <id> print the same.

Research on the web

When a question needs the public web (how a vendor's API works, a public figure to compare against), the assistant in the app does not search itself. It writes the questions and hands them to the researcher, a separate helper that searches the web and reads pages and has no access to your data: no tables, no notes, no keys. Before anything leaves, you see the questions word for word on a card, with the sites it may read and the cost (up to 15 searches, about 12 cents), and you press Run it. Only those questions leave, to a search company. A question that carries an email address, a figure of more than four digits or a value from your data is refused before the card is shown.

When you give the interview your website, it makes two searches of its own: your business name with your website, and your business name with "jobs" (Context and definitions says what it keeps). Nothing else is searched without a card.

It runs in the background. The chat shows it working, then the note: what it found, with the page each fact came from. The assistant reads the note and answers, or reads the docs pages it found and builds the source. The sites on the card are allowed in that chat, so you are asked once. Reading the note counts as reading outside your warehouse, as a page the assistant reads does: a dashboard it writes afterward waits for you to press Load, and a card to send data out says the chat read the web.

An admin chooses in Settings, Company, Web search: Ask each time (the default), On (the card still shows the questions, and it runs without waiting, unless the questions repeat words the chat read from your documents, your notes or the description of your business: then it waits for Run it), or Off. There are 200 searches a day, and the same question twice in a day counts once. The inside-only AI policy turns it off. An agent on your own computer uses its own web search; ovs research "<question>" runs the researcher from a terminal and prints its note.

What's logged

Every query, every insert, every note, under the agent's own name, with how long each took. Creating and revoking keys, revoking them all, and logging a laptop out record who did it and each key's name and first characters, never the secret key. An AI policy change records its old and new choice. Each access change is recorded when it happens; using a key later does not repeat its creation or revocation. These changes appear in Settings, Activity, as well as the log and paper trail, and on the list of admin actions, which keeps 90 days. An admin exports that list, the query log or every agent step, each row with the key that did it: Export on Settings, Activity saves a CSV from the day you pick; for CSV or Excel at a terminal, ovs actions, or GET /actions. The assistant does not read the list. On Settings, Agents, open a row under What agents did to read the full saved request, result, error and time taken. Failed steps are marked even when the preview is clipped. The latest 50 steps are here; the Settings, Activity link opens the longer record for an admin. An agent under your account is never anonymous. Every web search the researcher makes is on the record with its words. When read_file says a document is waiting or being read, follow its retry interval; no pages yet is not an empty document.

Kept files follow their dataset: its readers see them, and a masked reader cannot open the original bytes. A note made from a fact in a document follows the document the same way, in its history, in search and in where it came from; who uploaded a file and when is told only to a key that can see the file. A key that sees a dataset masked cannot search inside a table with personal details in it, nor change which of its columns are sensitive. A file, or a spreadsheet made into a table, may be 512 MB; the size is counted as it arrives, whatever the sender says it is. Account-wide files are for organization admins. The older upload commands follow the same rules; ovs upload put uses your project dataset, or --dataset. Python models may name only files their writer may open. For scheduled models, keep the files in a dataset the scheduled run can read.

Limits per key

• 1,000 rows returned per query, 30 seconds per query.
• 120 requests a minute, 20,000 a day.
• A request's body may be 32 MB at most; a file or an upload goes through its own door, which takes 512 MB.
• All adjustable per key when a job needs more, except the body's size.