# 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 maplith@1.2.0-rc.1 setup claude`. Codex: `npx --yes maplith@1.2.0-rc.1 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](/docs/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.