> ## Documentation Index > Fetch the complete documentation index at: https://docs.nuphos.ai/llms.txt > Use this file to discover all available pages before exploring further. # Approvals & audit > Keep humans in control of what the agent changes — with explicit approvals and an attributed audit trail. The agent can investigate freely, but it can't **change** your infrastructure without a human saying yes. Approvals and the audit trail are how Nuphos keeps you in control. ## Approvals via plans Every change the agent wants to make is packaged as a [plan](/agent/plans) — overview, steps, risk, and cost — that a team member must approve before it runs. Nothing executes from a `proposed` plan; it has to move to `approved` first. Decide *who* can approve using: * [Team roles](/collaboration/teams) — Administrators (and Editors) can act on plans; Viewers cannot. * [Member allow-lists](/security/access-control) — only people allowed on an account can drive changes against it. ## Command-level approvals Plans gate the *changes* the agent proposes. One level down, [Auto-authorization](/security/auto-mode) governs the individual shell commands the agent runs as it works: read-only commands run on their own, irreversible ones always pause for you, and you set standing rules for everything in between — approving a command **once**, **for the session**, or **always**. ## Permission grants When a least-privilege role hits an `AccessDenied` wall, the agent doesn't just stop — it can propose a narrow **permission grant** (attach one policy, grant one role) for an Administrator to approve. The agent never edits IAM itself; Nuphos applies the change through a dedicated permission-admin binding. See [Permission grants](/security/permission-admin). ## Audit trail Plan approvals are **attributed and timestamped** — Nuphos records who approved or rejected each plan and when. Combined with each command's captured output, this gives you a record of what was proposed, who authorized it, and what actually happened. ## Temporary access Because credentials are [short-lived and per-session](/security/iam-trust), access is naturally time-boxed: a session's credentials expire in about an hour rather than lingering. Grant access for a task, and it lapses on its own. For the tightest control on a sensitive account: keep its role read-only, add only the people who need it to the allow-list, and review plan decisions before approving.