AI agent control glossary: HITL, MCP, permission gates, kill switch, audit trail
Plain definitions for the terms you need to control AI agents: HITL, MCP, permission gate, permission policy, kill switch, audit trail.
A permission gate is the checkpoint that pauses an AI agent before a risky action and asks a human to allow or deny it. A kill switch is the control that stops a running agent or session immediately. An audit trail is the record of what the agent did, what it asked, and who answered. Together they are how you keep an AI agent under control instead of just hoping it behaves. Each term below is defined in one line, then expanded with context and a short example.
Key takeaways
- A permission gate decides per action; a permission policy is the set of rules that drive those gates without asking you every time.
- A kill switch stops work in progress; an audit trail proves what already happened. You want both.
- Native notifications are now table stakes. The control that matters is the policy plus audit layer underneath the pings.
Human in the loop (HITL)
One line: A workflow where an AI agent pauses and waits for a person to approve, deny, or answer before it continues.
Human in the loop is the parent idea behind everything else here. Instead of letting an agent run end to end alone, you insert a person at the decision points that carry real risk: writing files, pushing code, spending money, sending an external message. The agent does the work, the human makes the call. Pushary's human-in-the-loop flow lets the agent ask a question and wait for an answer from your phone, the web, or Slack.
Example: Claude Code is about to run git push --force on a shared branch. With HITL it stops, sends a push notification, and waits. You tap deny from your lock screen, and the push never happens. We also publish a Human-in-the-loop manifesto for the principles in long form.
MCP (Model Context Protocol)
One line: An open protocol that lets AI agents call external tools and services through a standard interface.
MCP is how an agent reaches outside its own context: query a database, send a notification, ask a human. A Pushary MCP server exposes tools like ask_user and wait_for_answer, so any MCP-capable agent can pause and request a decision without custom plumbing. The server is listed on the official MCP registry as io.github.Pushary/pushary.
Example: Gemini CLI connects to Pushary over MCP and gains the ask_user tool, so a notification lands on your phone when it hits a step it should not decide alone. Claude Desktop connects the same way through a paste-one-URL connector, but there it can only notify and ask, not enforce a gate, because Claude Desktop has no hook system.
Permission gate
One line: A checkpoint that intercepts a specific agent action and requires an allow or deny before it runs.
A gate is the enforcement point. It sits in front of a tool call and blocks it until a decision exists. For CLI agents (Claude Code, Codex, Gemini CLI, Cursor, Hermes) the gate runs through a hook, so a denied action genuinely does not execute. This is the difference between a notification and a gate: a notification tells you something happened, a gate decides whether it happens at all.
Example: an agent tries to delete a directory. The gate catches the command, sends it for approval, and holds the agent until you answer. Deny, and the delete is dropped. You can also deny with a reason, which gets sent back to the agent so it can try a safer path.
Permission policy
One line: The set of rules that decides, per action, whether to auto-allow, ask a human, or auto-deny, so gates fire only when they matter.
A policy is what keeps gates from nagging you about ls. Pushary policies match on tool arguments, not just the tool name, with exact, prefix, and tool-level precedence. So you can allow git status while still gating git push. A read-only safe floor auto-approves proven read-only shell commands like cd, cat, git log, and grep. That floor was decided from 1,721 real production questions, not guessed. Permission Autopilot then mines your own approve and deny history into one-tap rule suggestions.
Example: you approve npm test three times. Autopilot notices and offers a rule to auto-allow it. Read more on the permission policy page or the policies docs.
Kill switch
One line: A control that stops a running agent or session immediately, on demand or automatically at a budget.
A gate stops one action before it runs. A kill switch stops everything that is already in motion. Pushary's cost guard tracks a session's spend from the transcript and can kill the session when it crosses a daily budget, so a runaway loop does not bill all night. You can also stop a session yourself.
Example: an agent gets stuck retrying an expensive call. The cost guard hits your daily limit and ends the session without you watching it. Details are on the kill switch page and the kill-switch docs.
Audit trail
One line: The durable record of what an agent did, what it asked, and who answered, so you can review or prove it later.
Gates and kill switches act in the moment. The audit trail is the record you go back to afterward. Pushary writes a per-session receipt with structured tool-action metadata, a what-changed view, and an answer-source record for every decision, so you know each approval came from phone, web, or Slack. History is exportable, so you can pull the full record when you need it.
Example: a week later someone asks why a file got deleted. You open the session receipt, see the agent requested the delete, see that it was approved from the mobile app at a specific time, and you have your answer. See the audit trail page or the audit log docs. For honesty: Pushary is GDPR-aligned but self-assessed, with no SOC 2 or ISO certification.
Common questions
What is the difference between a permission gate and a kill switch?
A gate acts before an action runs and decides whether to allow it. A kill switch acts on work already running and stops it. You gate the rm command before it executes; you use the kill switch when a session is already looping and burning budget.
Does an audit trail prevent bad actions?
No. An audit trail records what happened so you can review or prove it later. Prevention is the job of gates and policies. The trail is what lets you answer questions after the fact and spot patterns worth turning into new rules.
Do all agents support enforced gating?
CLI agents like Claude Code, Codex, Gemini CLI, Cursor, and Hermes support enforced gating through hooks, so a denied action does not run. Claude Desktop has no hooks, so its connector can notify and ask only. On iOS the cross-origin deep link is broken, so the mobile experience uses a pending-questions inbox instead.
These six terms are one product, not six. The control panel for AI agents ties gates, policies, kill switches, and the audit trail together so the same decision you make from your phone is enforced at the agent and recorded for later. Start from the quickstart, or see what each tier includes on pricing.