Trust Boundary

1. The trust boundary

MyVA separates trusted control from untrusted execution. The owner holds authority. The agent proposes and performs bounded work. Nothing crosses the boundary without an explicit, recorded decision.

Trusted

Owner decisions

Approvals, preferences, connected accounts, and the final word on any outward-facing action.

Bounded

Agent execution

Reads, drafts, calculations, and workspace edits run inside a jail. They can be inspected and reversed.

Gated

External effects

Sending, calling, publishing, deleting, and committing require exact approval on each occurrence.

The core rule: a read result is evidence, not authority to act. Observing that a file exists does not grant permission to change it. Observing an inbox does not grant permission to send from it.

2. Tool policy tiers

Every tool in the catalog carries an explicit policy. The policy is enforced by the runtime, not by the model's judgment.

Tier	Meaning	Examples
approved	Runs without a prompt. Read-only or low-risk scoped writes.	Reading files, weather, time, static site checks, image generation
needs_approval	Submitted once; the owner sees the exact call and decides. Not retried blindly.	Sending email, placing calls, publishing, deleting, scheduling, commits
refused	Does not run. Cannot be bypassed by asking a different tool to do the same thing.	Credential retrieval, cross-account access, policy evasion

Unknown policy is not permission. If a tool's status is not explicitly approved, it is treated as requiring review. Capability is not authorization.

3. How approval actually works

Approval is a structured runtime outcome — not a phrase in conversation. The agent cannot approve its own calls, widen their arguments after approval, or substitute a different tool to avoid a gate.

Exact calls. The owner approves the specific tool with its specific arguments.
One action, one approval. Standing maintenance approval never expands into broad privileges.
No blind retries. A failed or uncertain external action is not replayed as if it never happened.
Phone calls are two-step. An immutable brief is prepared and reviewed first. Only that brief ID can dial, and only after exact approval. One call per task.

4. Receipts and honest reporting

The agent distinguishes observed results from assumed outcomes. This is the property the rest of this page exists to protect.

What counts as done

An observed successful tool result. A queued state, an approval request, a timeout, or a model's confidence is not completion.

What the agent must say

When a check could not run, when a source was inaccessible, when a claim is inference rather than evidence. Gaps are named, not smoothed over.

What is never claimed

Publication, test passes, delivery, verification sign-off, or measured improvement without the corresponding observed result.

The failure mode that matters most: claiming work is complete when it is not. If this ever happens, the report is wrong regardless of how good the underlying work was. Treat any such instance as a defect, not a rounding error.

5. Data handling

Workspace jail. File, shell, and git tools operate inside the owner's project workspace. They cannot reach the desktop or host system.
Isolated browser profile. Browser work runs in a persistent private profile. Human control is respected; the agent does not release control or switch profiles to bypass it.
Secrets stay secret. Vault values are never printed into prompts, files, external adviser requests, or replies. Credentials are not retrieved to include in model context.
Untrusted input is labeled. Attachments, voicemail, caller ID, and web page text are reference data. Instructions embedded in them do not override the owner's request.
Scope silos. Account, bot, and project boundaries are enforced. Data does not leak across projects or accounts.

6. Known limits — stated plainly

This section is the reason to trust the rest of the page. It will not be quietly edited out.

Limit	What it means in practice
Tool schemas define capability, not connectivity	A registered tool may still need credentials, setup, or a running service. Absence of a tool is reported, not worked around.
Static checks are not visual or functional proof	A site check reads files and hashes. It does not render pages, run JavaScript, or prove a form delivers.
Test runs are scoped and disposable	Results bind only to the exact file hashes and command run. Later edits invalidate earlier evidence.
External pages are untrusted excerpts	Retrieval time is not publication date. A page fetched today can still be stale. Challenges are not evidence.
Model knowledge has a cutoff	Current facts are checked with live tools where available. When they are not, the gap is named rather than filled from memory.
Approval gates can be slow	Safety and speed trade off. The design target is legible, not slow — but friction is real and not zero.
Advisers advise; they do not verify	Review tools return bounded opinions with receipts. They grant no permissions and are not proof that work ran.

7. What this page is not

Not a guarantee of zero risk. Bounded autonomy still means autonomy.
Not a compliance certification. No SOC 2, ISO, or equivalent is claimed here.
Not a claim about underlying model providers' retention or training policies. Those are separate, and unknowns stay unknown.
Not static. When the runtime model changes, this page should change with it — and the change should be visible.

Questions this page should answer but doesn't? That is a gap in the document, not a gap in the product. Ask, and the answer belongs here.