Agent keys & policies

Access for agents is governed by three independent controls: keys (who), scopes (what they see) and policies (what they may do). Everything an agent does lands in a durable audit log in your workspace.

Keys

Created in the app (or issued automatically by the claude.ai OAuth connector flow). Stored as hashes — Maplith cannot read a key back. A key you create is shown once, with a copy button beside it and beside the command that connects Claude Code: copy it then and store it in your password manager. Revocable in one click; revocation is immediate.

Scopes

A key can see the whole map, a set of domains, or single objects. The scope is enforced server-side on every call — search results, relations and findings are filtered to it.

Signal planning limits

Under Agents & access › Policies › Show details › Signal planning limits, an admin who sees all of the map can change the urgent and attention deadlines (1–90 days), and plans allowed per key and signal episode within 90 days (1–5). Defaults are 7 days, 30 days and 2 plans. Info signals keep a 90-day deadline. This limits how long an agent tricked by instructions in a signal can park work. Agents cannot raise their own caps. Changes require the same sign-in step-up as other settings and are audited with who changed them and the old and new values. They govern the next planning decision; existing plans keep their date, except that a signal whose severity rises brings an agent's plan within the new severity's limit. A person can still take over or change a plan.

Daily spending limit

Some agents run on Maplith's own model account for your workspace, such as the hosted GitHub agent below. Under Agents & access › Usage › Daily spending limit, an admin who sees all of the map sets the most they may spend in a Copenhagen day, in US dollars (up to a thousand). Every workspace starts with a small default, which the card shows; 0 means none of them runs. Changing it needs the same sign-in step-up as other settings and is audited; no agent key can change it.

Reaching it holds work instead of dropping it. An agent that would pass the limit does not start; the card says when the limit was reached and how many items wait. Held work goes back in the queue after midnight Copenhagen time, or as soon as you raise the limit. Work that has waited a whole week is let go, and the card counts it. Agents you run on your own model account, such as your own assistant connected over MCP, are not counted here: they are on your own bill.

Members, roles and who approves

An admin invites a colleague under Settings › Members & roles with Invite member, choosing a role. The role decides what the person and their own agent may do:

• Viewer. The person reads the map, and their agent reads only.
• Builder. The person uploads and reports work, and their agent acts with approval: an admin approves each change.
• Admin. The person manages members, connections and approvals, and their agent may also act directly.

The invited person gets one mail with the workspace's name and their role, and one click signs them in. Until they have signed in, the member list shows Invited · not signed in yet on their row, counted in the heading as "N members · M invited" (N is every member, M those who have not signed in). An admin can Send again, or Cancel invite under the row's More menu: the link in their mail stops working, and the invite can be sent again.

The first thing an invited member sees on Home is a card with Connect your agent. It goes away once they have connected their own. The member's own connections are listed on Fieldwork, read-only: the assistant, what it may do, whether it may upload, and when it last called. Disconnect, under More, takes the connection away at once and keeps the work it reported. A member can only disconnect an agent they connected themselves; it never grants anything. If connecting fails, Fieldwork says how it ended for 24 hours (for example, "Claude was not connected: you chose Deny on the consent page.").

An agent's request to change something waits for one kind of person: an admin whose view of the map covers it. A builder never decides their own agent's request; their row reads "Waiting for an admin" with the admins' names. When a request cannot be approved yet, the card says why in place of the Approve button, and Deny stays. Approvals in Slack are set up under Agents & access › Policies; where they are not on yet, approve in the Inbox or from the mail.

Policies (autonomy)

A manually created key starts read-only. Personal OAuth connections start with approval-based work and uploads selected for admins and builders; viewers connect read-only. Acting directly is an explicit admin choice. An admin can change a key's policy under Agents & access › Connections. The agent sees the change on its next call; a change also withdraws any unspent action grant. New read-only consent grants no writes. An admin can separately bind the key to a live check to report observations. Existing keys retain their separate consents. The policies:

• read_only — read tools. Legacy keys may also retain off-ladder consents: suggest_feature where configured, and with it list_requests (what you or your human asked Maplith for; its own requests stay empty until the key can ask), join_review for keys not locked read-only for good, check_setup outside demo workspaces (and in the directory review sandbox); where wake-ups are on, the key’s wake endpoints and their deliveries are get_map_overview’s your_key.wake_ups. Rules add get_rule (the list without a rule_id; it lists the rules the key may see and reads one with the instructions of its live checks) where offered, and report_observation only for a key bound to a live check. An action policy adds request_action (its op withdraw takes a request back), list_requests and recording its own request outcome with record_action (a key that acts with approval or autonomously is listed the first two without one); where Maplith signs grants, redeem_action_grant is listed wherever those two are, and redeems only for a key that holds a policy. The published demo key stays locked read-only, and so does a key an app-directory reviewer made, except in the directory review sandbox (a demo of fictional data), where it acts with approval under fixed sandbox policies, and the sandbox approves at once what would wait for a person, so a reviewer sees the whole path. get_map_overview’s stated (the relationships people, agents and shared artefacts stated, with what the scan found) comes with whole-map scope and an unlocked key. Action tools are otherwise absent and refused if called anyway.
• act_with_approval — the action tools appear, and with them request_action, list_requests, and so request_action's op withdraw, even before any action policy exists (below). update_finding_status queues the change as a pending approval; nothing happens until a workspace admin approves it in Agents & access › Activity, and the agent is told so in the response. take_signal and record_action write straight away, because a note about work done elsewhere is not a change to anything — except a close as not_an_issue or wont_fix, which keeps the signal quiet if it comes back unchanged, and so waits for an admin's approval as well. configure_metric, register_automation, correct_source_system, an answer_question of kind grain, schema_dialect or lineage_direction, and state_relationships are refused (the last is not listed): the approval queue applies finding-status changes and nothing else, so tracking is turned on under Business map › Metrics instead, an automation is registered by a key with the autonomous policy, and an admin records a DMARC policy step on the Cloudflare connection under Data sources › Systems.
• autonomous — every action tool applies immediately, and the same three request tools are listed without a policy. Every use is logged with actor, target and change.

Report work without a scan. An agent allowed to act can use record_action with a work argument: a lowercase kind of work, up to five map object names and non-personal references (such as an edition number or page slug), the system you did the work in, and an optional time within the last 90 days. Always send system: the system's name as list_sources gives it, or as the product writes its name, never a link, an address or a person. Maplith stores it under the spelling the map already knows when it knows one, and says when it has not seen the system before. It also sends a short summary and outcome done or skipped. Maplith tries to mask summaries and links, best effort. Send the kind of work and references, not message text or personal values. References changed by masking are refused. Also name the client or channel the work was for among the objects, by company or channel name and never a person. The report appears in the agent activity log and any stated value joins the value summary. It starts no scan, spends no daily scan allowance and raises or closes no signal. Members restricted to part of the map do not see these records without a signal or request. A key limited to domains or objects cannot read back even its own independent work reports or their value through get_value_summary. A read-only key needs a workspace admin to grant write access under Agents & access › Connections, even if it may record its own request outcomes. Upload source exports and documents through submit_sources; report your agent's own work through the work argument. A small prose upload gets a conditional reminder and still proceeds. At the next existing scan, work reports feed process discovery using the latest 20,000 records within 365 days. References connect the steps of each case; count-only reports make no case. Discovery still needs at least five cases and two step kinds. This starts no extra scan. Summaries and links stay out of the process log. Completed work repeated across at least three distinct cases in the last 30 days can become a playbook draft when each step was reported in at least 60% of that object's cases; they need not follow one identical sequence. An admin reviews it in Rules & know-how › Playbooks; it is never activated automatically. Rejection or deletion holds that kind of work for 90 days in this workspace; later reports do not extend the hold. Agents limited to part of the map contribute too, and people see a draft only when their access covers what it is about. An admin who sees the whole map decides. At most three proposals are made per scan, within the shared daily and waiting draft limits. Different kinds from one agent can still fill that queue. Work needing a person belongs on its signal, or in your conversation when there is no signal.

How work differs by client. When your agents name the client or channel next to the work, Maplith can notice that one group of clients does the same routine differently: an extra step, or a step in another system. Each difference is kept as a fact on that client or channel, not in the playbook, and a workspace admin confirms it in Rules & know-how › Playbooks, under the routine it belongs to; nothing applies until then, and a client is never removed without a person. It takes at least three cases, at least 60% of the group's cases and at least three reports; clients that behave alike share one fact. An agent works for one client by passing context, such as {"client": "<company name>"}, to get_task_context or get_object: it is given the routine and that client's confirmed variation, and nothing of any other client. Without context, the answer only says how many confirmed variations exist. These are facts about how work is done: counts and the names of companies or channels, never messages or rows. An object is used as the client only with evidence that it is a company (a CVR, VAT or organisation number beside its name, or a company name column) or a channel, and with no column that names a person: contacts, employees, a web shop's customers, and a company export with a contact person or owner column are never used. Maplith tries to keep out any name your masking terms cover, however it is written (jens-hansen for "Jens Hansen"), and hides a name it already kept once you list it. Only keys and members that see the whole map get variations.

Where work happens. route, get_task_context and list_sources say where agents reported doing work: each object carries work_done_in (up to three systems, with counts of completed reports in the last 90 days, their kinds of work and when the last one came), and each system in list_sources carries work_done_here. Every entry has an item_id and a status: *auto-detected* (auto_detected: true) until a person or an agent confirms it, then *confirmed by a person* or *confirmed by an agent*; *ruled out by a person* or *by an agent* means the work does not happen there; *removed by a person*; or *not reported since <date>*. What agents report goes onto the map by itself: where an object is worked on is added at the first completed report, marked auto-detected. If you checked an entry in your human's own systems, confirm or correct it with answer_question (kind auto_detected). Where you could not check it, tell your human before acting there on that basis alone. A playbook proposal from repeated work names the system for each step where most reports agree.

What the map does not have yet. A key that sees the whole map may name an object type the map lacks in work.objects, such as campaign. The report is kept and the reference for that name is dropped. Once completed reports name it on at least three reports over two days in the last 90 days, Maplith adds it to the map, marked *auto-detected*, in the domain Fieldwork, with counts and kinds of work as its only evidence; the answer to the report that added it says so (work.added). It appears in the Atlas with its system until an export builds an object of the same name, and no scan removes it. It is added only from a key that may act and sees the whole map. A key limited to part of the map can only name objects it sees: any other name is refused, in the same words whether it is absent or outside the key's scope. At most 10 new object types and 50 new pairs are added a day per workspace; past a limit, the rest wait until the next day.

What reaches a person. Only three things: something agents stopped reporting for 60 days while they still report other work (a person keeps it or removes it; nothing is removed automatically), two agents who disagree (or an approval key's correction that waits), and agents who report against a person's decision. They appear in the Inbox and under Fieldwork › Needs you, and only an admin who sees the whole map decides. A person's decision never changes on its own. A person confirms or corrects an item on Fieldwork: confirm it, say it is the same as an object on the map (reports count there from then on), say it is not something you work on, move it to a domain, or remove it. An item that is a person's name is taken off the map and added to your masking terms; Maplith then tries to refuse reports that use it (best effort). Every change is kept in a history with who made it and why. A confirm from an agent applies for any key that may act, unless it hands over only; a correction applies for an autonomous key and otherwise waits for a person.

Playbook refusals. Where whole-playbook proposals are available, declining or deleting a proposal keeps the same kind quiet for 90 days in that workspace, even after deleting its history. Another agent or a different title does not bypass that choice. A person still decides every proposed routine.

Fieldwork. After your first map, open Fieldwork from the workspace home to connect your own assistant with its own key. The map learns from the work you and your agents do; your colleagues can connect theirs too. Claude Code: npx --yes [email protected] setup claude. Codex: npx --yes [email protected] setup codex, which opens sign-in; only if it did not open, run codex mcp login maplith. ChatGPT and Claude.ai connect through their custom connector to https://app.maplith.com/api/mcp. Ask the assistant to report its work through record_action with work, rather than upload its notes. New connections for admins and builders offer Act with approval and uploads selected; viewers connect read-only. To report work from an existing read-only connection, reconnect with an admin or builder account and choose “Act with approval”, or ask a workspace admin to change your access. Other actions keep their approval rules. The home shows agents' work-report counts since Monday, Copenhagen time, under the same access as Agents & access › Activity. Counts are taken together, so new reports arriving while the page loads do not shift the total. A report counts once, regardless of how many cases it describes. A key is an agent connection, not a count of people. Reports start no scan.

Hand over only. Beside the ladder, an admin can set any key to *Hand over only* (Agents & access › Connections › More). Such a key may still read, take signals and ask before it acts, but record_action from it accepts only needs_human on a signal: it can hand a signal to a person and never close one. It can also report independent work as done or skipped, without changing a signal. Maplith enforces it on every record, so text the agent reads (a sender's name, an issue title) cannot talk it into closing a signal. Its answers to Maplith's questions about your columns wait for a person's approval too, even where its policy is autonomous, since answering the last column closes the question's signal. Use it for an agent that triages and hands over. *Let it close signals* turns it off; both are in the audit trail.

Your delegate. A workspace admin who sees the whole map can make one of the workspace's keys their delegate, one at a time (Agents & access › Connections › More › *Let this agent act as my delegate*): a key that acts, with approval or autonomously, sees the whole map and does not hand over only; a member's own connection is only theirs to name. That key then works for the admin on what waits on a person. record_action settles a signal held for a person (a hand-over, a proposal waiting for approval, or the admin's own take; never another member's), and its not_an_issue and wont_fix close at once instead of waiting for approval. A proposal still waiting on that signal is closed, since nothing is left to decide. answer_question answers what identifies a row, a schema's dialect and which file holds the original as the admin's own answer, so it stands as a person's; it leaves a question another member took, or another agent holds, to them. A person decides whether a personal-data or security finding is not an issue or will not be fixed; a delegate may still record one fixed. A delegate never settles a customer report, a blocked customer, a security alert, a secret, DNS, deletion or migration matter or any legal matter, and it does not approve requests or alter keys, members or access. Field identity answers keep their own rule. Every act is recorded as done by the key as the admin's delegate, and the audit trail names both. A question Maplith asks is answered, never closed unanswered. It stops the moment the admin is no longer an admin who sees the whole map (being made admin again does not bring it back), the key's access narrows or it is set to hand over only, and any admin can stop it under the same menu; naming and stopping are in the audit trail.

A declared/measured field-identity conflict always needs a person's choice, even with an autonomous key. A person-confirmed field keeps continuing when its content corroborates it; a changed declared key becomes a question beside it and never detaches the field. Task context links to the question in Business map › Glossary.

Propose an alert. An agent that acts with approval or autonomously can use request_action with op: proposal to propose a rule or a live check for a whole-map workspace admin. No operation policy is needed to propose. The rule is checked against the map the key sees, including its joins; a whole-map admin approves it, and an approved rule is on at once. A live check starts only after a person approves it. Approve in the app or linked Slack. At most 10 proposals per agent wait at once, with 30 a day and a seven-day expiry. If the part of the map it is about, its rule or key changes before approval, nothing is saved: the proposal is closed and the agent is told to check and propose again. A rescan that leaves that part of the map as it was changes nothing. Unrelated explanations, field types or join labels do not close the proposal. Personal-data classifications still count. Personal-data pins count only on its objects’ sources. Workspace masking terms are rechecked against the stored rule and the live check's displayed text; an unrelated term does not close it. If those settings cannot be checked, approval waits.

Actions in your own systems (ADR-0015). Separately from the ladder, an admin can declare operations under Agents & access › Policies (pause ad spend, create a purchase order, issue a refund, reply to a case) and give a key a policy for each: approval or not, limits above which a person decides, and a daily rate. A key that acts with approval or autonomously sees request_action from the start, and a read-only key sees it once it has at least one policy: the agent asks before it acts and gets allowed, pending or denied. Any external operation without a policy is denied. For an operation the workspace has declared, the denial says an admin adds a policy for it under Agents & access › Policies › What each agent may do, with a link to it; for one it has not, the denial says so, and an admin declares it under Agents & access › Policies first. A key that acts needs no reconnecting after an admin adds a policy: where Maplith signs grants it is listed redeem_action_grant from the start too, and that redeems once the key holds a policy. Every decision is logged. Maplith never holds the credentials to those systems and never performs the action; the agent does, when the answer is yes. A pending request waits in Agents & access › Activity, where a workspace admin approves or rejects it. The answer carries approve_url, a link to that one request, for your agent to show you; it opens the request in Maplith after you sign in, and decides nothing by itself. The approval mail links to it too. Where direct Slack decisions are enabled for your workspace, link your own Slack account from Account security after two-factor sign-in. A linked Slack account counts as your second factor for a decision; unlinking stops it immediately. Your current workspace permissions still decide what you may approve. Slack records your decision without opening the app, and the decision keeps your Slack identity. Changes to keys, access or action policies send a confirmation afterwards. Approving re-checks it against the key's policy and scope as they are at that moment: a key revoked, a policy removed or lowered to propose, or a target that has left the key's scope closes the request instead. The agent learns the decision by asking again with the same request and the same idempotency_key; no agent can approve a request over MCP. At most 20 requests per key, and 50 per workspace, wait at once. The same keys see list_requests (a key's own requests and where each stands, with the state of the signal each named) and request_action with op: withdraw: when a request no longer needs you, because the work was done another way or the condition resolved itself, the agent takes it back with a one-sentence reason. It is then withdrawn, neither approved nor rejected, nothing is done, and it stays in the action log with the reason. Only the key that asked can withdraw its request, and only while it waits; one you have decided stays decided.

Signed grants (ADR-0015 §4.2). Where Maplith is configured with a signing key, an allowed answer also carries a short-lived grant: a token signed with Ed25519 and bound to your workspace, the asking key, that one request, and the system, the operation and the target kind of the action — and to the exact target and parameters your agent sent. That last binding is a keyed digest (HMAC-SHA256 under a random salt minted for that one grant) over the action as your agent sent it, before Maplith's best-effort masking: your executor holds the real values, recomputes the digest from the job it was handed, and refuses a grant whose parameters differ — a grant for a refund of 120 never pays out 999,999. Maplith keeps only that keyed digest, and its salt sealed under a key held outside the database and deleted once the grant is used, so the stored value cannot be turned back into the amounts or addresses it was taken over. Never copy a digest out of the grant to compare with: compute it. The exact encoding is in the reference executor below. Your own executor — the piece of your code that holds the credentials to the system being acted in — verifies it against the public keys Maplith publishes at /.well-known/maplith-action-keys (cache that document for at most five minutes) and refuses anything without a valid one, so the refusal happens where your credentials are rather than only in Maplith's log. Verifying is not the same as being allowed. A signature says the token was minted by Maplith; it says nothing about whether the grant has already been used, and Maplith's signing key is global, so the workspace in the token has to be checked too. The authority is the REDEMPTION: a grant is good for ONE action, the executor spends it with redeem_action_grant at the moment it acts, naming the system, operation and target kind it is about to perform (Maplith refuses a grant issued for any other), and it acts only if the answer is redeemed. Every later attempt on the same grant is refused. Any key of the same workspace that has an action policy may redeem, since the executor is usually not the agent that asked; no key of another workspace ever can. Revoking an agent key under Agents & access › Connections revokes the grants already issued to it and not yet spent, in the same step, so an executor holding one is told revoked and must not act; a revoked key cannot redeem either. Changing a key's action policy for an operation does the same for that key and that operation: a new rung, limits or daily rate, removing the policy, or changing the operation itself in the catalogue (its parameters, the params that can be limited, or its target kind) revokes the unspent grants decided under the old one, and a request allowed under the old policy is issued no grant. Saving a policy unchanged revokes nothing. Until you run an executor that redeems, the gate governs cooperating agents exactly as before — signing adds a refusal point, it does not take one away.

Pause all agents

The emergency brake. Under Settings › Danger zone, a workspace admin can pause every agent in the workspace at once, with one click and a confirm, and a short reason if they like. From that moment:

• Every agent key is refused from its next call, reads included: keys you made, assistants you connected such as ChatGPT or Claude, and any agent of your own. An agent in the middle of a task stops there. The agent is told that an admin paused the agents, since when, and why.
• No action can be requested, no approved action can be carried out, and no outcome recorded until the agents run again.
• Maplith's hosted GitHub agent does nothing for the workspace.
• You and your colleagues keep using Maplith as before, the assistant on your Home page included, and scans keep running.
• Nothing is deleted: keys, policies and waiting approvals stay as they are.

Home shows a banner to every member while the agents are paused. They run again only when an admin chooses Resume agents — never on their own. The pause and the resume show on Home, in the audit trail (who and when), and in every agent call; they raise no signal.

The hosted GitHub agent

Connecting Maplith Agents (the Maplith GitHub App that can write) adds a policy on the integration itself — a ladder, and each step is an explicit choice:

• read_only — the agent never acts.
• autonomous — the agent-fix label on an issue in a private repository makes the agent post one grounded analysis comment (map context: your objects and open findings).
• propose — additionally, the agent-pr label makes the agent author a remediation proposal and open a pull request containing a single markdown document. It never merges; humans review and decide. Raising a policy never happens implicitly — an integration set to autonomous stays comment-only until you choose propose.

Both are deduplicated per issue and logged in your workspace under Agents & access › Activity with token counts. They stop for the day at your workspace's spend ceiling (above) and at 50 actions a day. Either way the issue event is held, not dropped: it is taken again after midnight Copenhagen time (or when you raise the ceiling), oldest first, for up to seven days; one still waiting after that is let go, and the card in Agents & access › Usage counts it.

The action log

Every external-operation request (request_action, op: ask) is one row under Agents & access › Activity in your workspace (admins and builders whose access covers the whole map — the log is workspace-wide): what the agent asked to do, on what, with which params and why; what Maplith answered; who approved or denied it and when, or that the agent withdrew it and why; where Maplith issued a signed grant, whether your executor redeemed it — when, and with which key — or it expired unused; and what the agent recorded afterwards. The agent closes the loop with record_action(request_id, outcome, summary) — only for its own request, and only once it was allowed or approved; a key with an action policy may do that whatever its rung. If the signal the request named is gone by then, or the key can no longer read it, the outcome is still recorded against the request and no signal is closed; a signal that still waits for work is handed to a person instead, so no other agent repeats it. Filter by key, system, decision, outcome and date, and export the rows as CSV or JSON for your own audit. Everything an agent wrote is shown as it was stored, after best-effort masking, and the rows are kept for 12 months.

Correct which system a file belongs to

On Data sources › Scans, an admin who sees the whole map can choose Correct this system: move selected files to another system, split them into a new system, merge a whole system into another, or rename it. Use exact file paths; Maplith refuses a stale selection. Your choice is kept across later uploads: under a new dated wrapper folder, and when the same files come back without their folder. Split-file counters stay distinct. Wait for a queued or running scan to finish before correcting its systems. The catalogue changes immediately; the next scan rebuilds with that grouping. Object names, joins and access grants are unchanged. A rename keeps the system's stated answers; a merge or split keeps those answers on their original system rather than guessing which should win.

A correction only moves files between systems. It never removes anything from the map: when a later upload brings only some of a system's files, the rest of that system stays as it was. If a saved choice could mean more than one file of a later upload, Maplith does not guess: those files keep Maplith's own grouping, the scan goes on, and a finding asks you to choose on Data sources › Scans. Under System corrections, it lists the recent corrections; Undo takes back the newest one, and you can then undo the one before it. An undo is recorded in the audit trail.

An autonomous key that sees the whole map can make the same correction with correct_source_system, using names and paths from list_sources. Other keys ask an admin to use Data sources › Scans. This action does not use the approval queue.

Saved object selections

Inbox › Needs you, under setup notes, may show saved object selections without a current match while Maplith prepares stable source identities. It is a quiet check for members who see the whole map: no signal is raised, and existing access is unchanged.

Wake-ups

A key can have up to three wake-ups: addresses Maplith calls when a signal the key may see is raised, or a person decides one of its requests. A wake-up names signal ids only; the agent reads them with its own key, within its scope. An admin sets them up under Agents & access › Connections › Wake-ups, with the most wake-ups a day and the shortest burst window; a key with the policy "can act" may manage its own, never past those limits. See Wake your agent.

The audit trail

Notices. When a request waits for a person, Maplith mails the workspace's admins — all of them by default, or the ones chosen under Agents & access › Policies — with a link to Agents & access › Activity. The mail names the operation, the kind of target and why it waits, never the target itself, a param value or the agent's reason, and the link approves nothing by itself: you sign in and decide there. Each admin hears about a request once; past a number of single mails an hour (five by default) the rest arrive as one digest.

Agents & access › Activity shows every action: what acted, on what, and what it cost. What an action touched follows your own access: a member whose access is limited to some domains sees that an agent acted and when, but not the title of a finding, signal or metric they could not open themselves. Requests that wait for a person are decided on the same page, by workspace admins.