Approvals and safety

What Oktapod does on its own, what it asks about, how to answer, and how to give or take back permission.

Oktapod reads, searches, and answers on its own. It asks before it changes anything outside itself. This page explains where that line is and how to move it safely for work you trust.

#What runs on its own and what asks

Some actions always need a person, even with a saved permission: money transfers, actions that reach many people or things at once, destructive actions that cannot be undone, and messages without exactly one clear recipient. Nothing you say in chat and no saved permission removes that floor.

Background work, such as schedules and helper agents, never borrows permission from your current chat. It must be safe on its own, use a permission you set up for it, or ask.

#Answering an approval

An approval shows what will happen, where, and with what content. In the web app it appears as a card in the chat:

• Allow once runs exactly this action, once.
• Deny stops it. A denial is final; ask again if you change your mind.
• Always allow <app> appears for eligible reviewed apps and saves an app permission (see below).

Open Request details before deciding. The approval is tied to the exact recipient, target, and content you saw. If any of those change, Oktapod asks again. Approving "send this note to Sam" can never become permission to send edited text, or to send it to someone else.

You can answer the same request from the phone apps, from Settings → Apps & permissions → Approvals, or from a terminal:

oktapod approvals pending
oktapod approvals approve <approval_id> --reason "Checked the recipient"
oktapod approvals deny <approval_id> --reason "Not now"

#Saying yes for longer

An approval is single-use by default. For work you trust, you can widen it, always in a bounded way.

Coding in one workspace. When a coding action asks, you can say "approve this chat", "approve this session", or "approve today" (until local midnight). This covers matching coding actions in the same workspace. Sending, deleting, and other high-risk actions still ask each time.

One app. When an app's write action asks, say "approve for this app", "approve this app for today", "approve this app for this week", or name another duration. Oktapod stops repeating that prompt for that app during the window. App permission lasts at most seven days unless you say "always", which lasts until you revoke it. New or changed tools in that app still ask.

• "block this app" turns off all of its tools until you undo it.
• "revoke <app> app access" returns it to asking every time.

These app controls work from the web app, the terminal, or a direct chat with a paired owner. Group chats and unpaired senders cannot change them.

#Grants, fuses, and holds

For automations, the terminal offers three narrow tools. Each is limited to a specific effect and resource, and each can expire.

oktapod authority grants
oktapod authority holds
oktapod authority grant --effect <effect> --resource <resource> --minutes 15 --uses 1 --lane report --reason "One reviewed task"
oktapod authority fuse --effect <exact-effect> --resource <exact-resource> --minutes 10 --reason "One reviewed operation"
oktapod authority revoke <grant_id> --reason "Work complete"
oktapod authority cancel <hold_id> --reason "No longer needed"
oktapod authority review <fuse_id> --reason "Outcome checked"

After a fuse is used, you must review it before another fuse can be issued. For messages, always name the exact recipient; do not create wildcard grants. There is no setting that turns approvals off globally.

#How Oktapod decides

Every action is judged by its effect, not by the tool's name: what it touches, how far it reaches, whether it can be undone, and how many things it affects. A command described as "read-only" is not trusted on its word. Each decision lands in one of four lanes:

Actions Oktapod cannot fully understand, such as an unknown tool or a request whose scope is unclear, are blocked or sent to ask. They are never guessed safe. Every decision is recorded, so you can see later why something ran:

oktapod decision <run_id>
oktapod timeline <run_id>

#Credentials

• Connect only the accounts a task needs, with the narrowest access the app offers.
• Keys and passwords are kept in owner-only files on your machine and are never shown back in chat.
• Revealing or sending a secret is itself a high-risk action that asks each time.
• Rotate Oktapod's own access tokens with oktapod token rotate --name <name> and remove them with oktapod token revoke --name <name>. A new token's value is shown only once.

#Approvals are not a sandbox

Approvals decide whether an action is allowed. They do not physically stop a program from doing something else. For stronger isolation, combine them with:

• sandboxes and scoped credentials for code and tools;
• the optional egress proxy for Oktapod's web traffic; and
• host or container firewall rules.

Anyone who can change the Oktapod machine, its database, or its credentials is trusted by design. Protect that machine like the accounts Oktapod can reach.

#When something looks wrong