FUNCTION TOOLS · APPROVAL AND EFFECT WORKBENCH
Agent filesystem: read versus write authority
Edit real JSON arguments, inspect policy gates and watch an approved local function change a synthetic ledger.
Scroll the gateway horizontally to inspect all gates and ledger counters. The caption and JSON below give the same outcomes as text.
Request being reviewed
Your experiment
Use a read payload containing operation and path only. Compare viewer access with a write payload requiring operator permission and a newly approved intent.
Each gate takes eight inspection seconds, or use Next gate. Only reaching the final stage applies the planned local effect. Restart preserves the ledger; Reset synthetic ledger clears this page’s fictional state.
Returned output
Inspect the synthetic ledger
This browser-only gateway uses six handcrafted functions, not an ADK/Gemini service implementation. No emails, calendar invitations, network requests, real files, database queries or arbitrary code are executed. Email recipients are restricted to example.test; virtual files are two allowlisted map keys; arithmetic uses named operators, never eval. Calendar intervals use one synthetic day and no time zones or recurrence. Search is literal matching over three fixture sentences. Approval, role rules, hooks and receipt storage are illustrative application policies, not production security controls. Redaction changes two output fields only and is not a privacy or compliance guarantee. The ledger is held in page memory and is lost on reload. Function-tool concepts · Action-confirmation concepts.
Distinguish read authority from write authority
The filesystem experiment starts on Virtual files. Treat the two names as a deliberately tiny workspace. JSON arguments describe either read or write and one exact path: /workspace/notes.txt or /workspace/report.txt. A read must omit content. A write requires a nonempty content string of at most 2000 JavaScript characters. Enter {"operation":"read","path":"/workspace/notes.txt"}, retain Viewer, and inspect all seven gates: the output contains Original notes. Now change operation to write and add content: the viewer cannot mutate the ledger. Switch Role to Operator, approve the exact payload, and finish again. The stored string changes only after the final gate. Read it back as Viewer to verify the effect.
Reject names before dispatch
Example offers a valid write, malformed JSON, or a rejected traversal path. Try ../../private.txt, /workspace/../private.txt, a third workspace filename, or a backslash spelling. All fail the exact-name allowlist and leave both files unchanged. This is an in-memory map, not a real filesystem sandbox. It neither resolves symlinks nor simulates operating-system permissions, races, atomic disk writes, encoding, directories, or quota accounting. Unknown fields, null, arrays, missing content and content on a read are rejected. The raw JSON input is capped at 4096 JavaScript characters; this is not a UTF-8 byte quota. JSON parsing retains the last duplicate key.
Separate approval, hooks and retry identity
Role permission alone does not approve a mutation. Approve exact payload binds to the tool and parsed arguments; Revoke approval removes it. Editing arguments, role, hook, operation key or receipt policy clears approval. Hook policy can block mutations before execution or redact file content in returned output. Redaction leaves the internal ledger and retained receipt unchanged, so it is not a confidentiality guarantee. Operation key identifies one intended mutation. With receipt reuse enabled, restarting the same approved write returns its stored result without another effect. Reusing the key for different content is blocked; supply a new key and approve again. Reuse receipts becomes available after a successful mutation. Disable it to execute again: writing identical text can leave the same visible file value, so unchanged content alone does not prove deduplication. If another intent changed the file, replaying an old receipt returns its historical output without restoring the old content.
Inspect the full run
Play run advances one gate every eight inspection seconds: the complete run takes fifty-six seconds at normal speed. Pause freezes the inspection; Play resumes or starts another run after completion. Next gate advances and pauses, clearing any partially elapsed gate interval. Restart inspection returns to the first gate while retaining inputs, approval and ledger. Reset synthetic ledger restores the two original files, clears receipts and approval, and retains the selected request. Speed offers quarter, half, normal and double pace, settling elapsed time at the previous rate before switching. A hidden tab pauses. These durations give reading time and are not measured filesystem latency. A complete-run preview intentionally reveals the eventual outcome before execution.
Compare and record bounded effects
The other Function choices exercise the same policy chain: mock email only to example.test, a one-day fixture calendar with overlap rejection, two typed synthetic database keys, literal search over three sentences, and bounded arithmetic without eval. None calls a network service. Scroll the gateway horizontally on a phone; its caption and JSON ledger provide text alternatives. Capture baseline saves the current result and inputs; Replace baseline updates it, and Clear baseline removes it. Notes persist in this browser; Export notes downloads them. Expand experiment and Exit full screen change the viewing area. Record the exact payload, role, key, hook and resulting file string. Reload discards the synthetic ledger. The filesystem reading distinguishes shared read-only reference data, per-session scratch and durable artifacts. This experiment covers operation authority on two local strings only: it has no session routing, snapshots, quotas, symbolic links, durable storage or concurrent writers. The file-tools reading extends the discussion to real bounded reads and write preconditions. This fixture does not implement ADK itself or certify a production confinement policy.