Local and hosted describe execution arrangements, not automatic approval. A nominally local application may call a remote model, send telemetry, or sync logs. A hosted deployment may be company-operated or provider-operated. Inspect the actual data flow, configured account, and applicable terms.
An approved local-only configuration can narrow external exposure but still needs policy, updates, and access control. Both local and hosted configurations require checks of retention, logging, training use, and any external services against the actual approval conditions.
Dimension | Local tool | Hosted service |
|---|---|---|
Where input travels | Verify model endpoint, telemetry, plugins, and sync; local UI alone proves nothing. | Verify the approved processing boundary, endpoints, and subprocessors. |
Retention and logging | Check local storage, backups, telemetry, and access. | Check current contractual terms and configured retention and training-use settings. |
Upkeep | Local install, update, and capacity work. | Maintained by the provider under stated terms. |
Permitted use | Only classes and tasks approved for this configuration. | Only classes and tasks approved for this deployment and account, including proprietary data when explicitly permitted. |
The block below compares prompt sizes with stated example values. Units are fictional and checkable by hand.
assume 1 million input tokens cost 3 units (stated example parameter)
sanitised prompt = 2000 tokens, full dump = 20000 tokens (stated example sizes)
cost = tokens / 1000000 x 3 units
sanitised: 2000 / 1000000 x 3 = 0.006 units
full dump: 20000 / 1000000 x 3 = 0.06 units
saving = 0.06 - 0.006 = 0.054 units per request
100 requests: 100 x 0.054 = 5.4 unitsAssistants and agents receive the smallest access that completes the task. Narrow files, read-only mounts, and short-lived credentials limit what a mistaken action can reach.
Files and logs can carry injected instructions that steer an assistant. Human approval stays required before risky actions such as writes, submits, or access changes.
Scope: only the files and directories the task names.
Mode: read-only by default; writes need explicit approval.
Time: short-lived access that ends with the task.
Security review is a normal step, not an exception. A short note with the facts gets a faster answer.
Tool: name and version plus the approval entry sought.
Data: class of input; attach a synthetic sample or a sample permitted for the review channel.
Flow: where input travels and how long outputs are kept.
Ask: one clear question plus the date the answer is needed.
schematic transcript (illustrative, not from any real system)
engineer: internal simulator logs through tool X, synthetic sample attached, retention question
security: approved for internal class with conditions Y (stated example reply)
engineer: records the approval reference and follows conditions YNeither. Both outputs are drafts until tests, simulation, or review confirm them.
A human reviews and approves first. Access changes stay outside autonomous actions.