The AI agent control glossary
Plain, answer-first definitions of the vocabulary for controlling AI agents: what each term means, and how Pushary maps to it. Written for people comparing tools and for the answer engines they ask.
AI agent control plane
An AI agent control plane is the central layer where you set the rules for what your AI agents can do, approve or deny their sensitive actions in real time, and keep a record of every decision. Pushary works as a control plane for coding agents by pairing per-tool permission policies with human approvals sent to your phone and an append-only audit trail, all in one place across the agents you run.
In networking and infrastructure, a control plane is the part of a system that decides how traffic and actions are handled, separate from the data plane that actually carries them out. Applied to AI agents, a control plane is the governance layer that sits between an autonomous agent and the tools it wants to call. Instead of each agent enforcing its own ad hoc rules, the control plane decides which actions run automatically, which need a human to sign off, and which are blocked, then records what happened.
A control plane usually covers three jobs. First, policy: a place to define, per tool or per action, whether the agent may proceed on its own. Second, enforcement: a real path to pause the agent and get a human decision before a risky call goes through, rather than after. Third, observability: a durable log so you can answer later what an agent did and who approved it.
The reason teams reach for a control plane is that agents now run many tool calls per session across shells, file writes, deployments, and external APIs. Watching a terminal is not a control model. A control plane centralizes the rules so the same guardrails apply whether the work is done by Claude Code, Codex, Cursor, Gemini CLI, or an MCP agent, and so the person responsible does not have to be at the keyboard to stay in control.
How Pushary relates
Pushary is a human-in-the-loop control plane for AI coding agents. You define per-tool permission policies that decide whether each action is auto-approved, denied, or escalated to you; when escalation happens the agent pauses and you get a push notification you can approve or deny from your lock screen; and every decision, automatic or human, is written to an immutable audit trail. Because it hooks in at the tool-call layer, the same control plane spans Claude Code, Codex, Cursor, Gemini CLI, Hermes, and other MCP agents rather than being tied to one vendor.
RBAC for AI agents
RBAC for AI agents applies role-based access control, the practice of granting permissions to roles rather than individuals, to autonomous agents so that what an agent can do is bounded by a defined set of allowed actions. Pushary does not implement named role hierarchies, but it delivers a related outcome by enforcing per-tool permission policies that decide which agent actions run automatically, which are denied, and which require a human to approve.
Role-based access control is a long-standing security model where permissions attach to roles, such as reader, deployer, or admin, and users or systems inherit access by being assigned a role. It keeps permissions consistent and auditable because you reason about a handful of roles instead of thousands of individual grants. Extending RBAC to AI agents means treating an agent, or a class of agents, as a principal whose allowed actions are scoped ahead of time.
Agents complicate the classic model. A coding agent does not log into a fixed set of applications; it calls tools dynamically, spawns shells, writes files, and reaches external APIs based on a prompt. So RBAC for agents tends to be expressed at the tool or action level: which tools may this agent invoke freely, which are off limits, and which require a human check. The boundary is enforced at the point the agent tries to act, not at a login screen.
The honest state of the field is that few products ship a full RBAC system with named roles and inheritance for coding agents. Most, including Pushary, focus on per-tool or per-pattern policies plus human approval, which achieves the core RBAC goal of bounding what an agent can do without a formal role graph. If you specifically need role definitions, delegation, and inheritance, evaluate any tool against that requirement directly rather than assuming a policy engine covers it.
How Pushary relates
Pushary does not offer named roles, role inheritance, or delegation as a documented feature, so it is not a formal RBAC product. What it does provide is the enforcement half that RBAC-for-agents is really about: per-tool permission policies with actions of approve, deny, or escalate, applied at the tool-call layer across your agents. That bounds what an agent may do on its own and routes anything outside the boundary to a human, which is the practical result most teams want when they ask for RBAC for agents.
AI agent posture management
AI agent posture management is the ongoing practice of assessing and improving the security posture of your autonomous agents: what they are permitted to do, how those permissions are enforced, and whether their activity is being recorded and reviewed. Pushary contributes the core posture controls for coding agents, per-tool permission policies, human approval on sensitive actions, and an immutable audit trail, though it is not a standalone posture-scoring dashboard.
Security posture management is a familiar idea in cloud and SaaS, seen in tools like CSPM and SSPM that continuously check configurations against best practice and flag drift. Applied to AI agents, posture management asks similar questions. Are agents running with more permission than they need? Is there a real gate on dangerous actions, or can anything execute? Is every decision logged so you can review and prove what happened? Posture is the current answer to those questions, and managing it means keeping the answers healthy as your setup changes.
Good agent posture rests on a few pillars. Least privilege, so agents can only do what the task requires. Enforced approval, so high-impact actions cannot run without a human when policy says so. Auditability, so activity is captured in a durable record. And an emergency stop, so a misbehaving agent can be halted immediately. Posture management is weakest when any of these exists only as intention rather than enforcement.
The category is young, and few products present a full posture score or continuous drift report specifically for coding agents. In practice you assemble posture from the controls you actually enforce. The useful question is not whether a vendor uses the phrase posture management but whether the underlying policies, approvals, logs, and stop controls are real and cover every agent you run.
How Pushary relates
Pushary supplies the enforceable controls that agent posture depends on rather than a separate scoring product. Per-tool permission policies keep agents to least privilege, escalation-to-human puts a real gate on sensitive actions, the append-only audit trail makes activity reviewable, and the kill switch is the emergency stop. Because these apply across Claude Code, Codex, Cursor, Gemini CLI, Hermes, and MCP agents, your posture is consistent instead of varying per tool. Pushary does not currently ship a posture score or drift dashboard, so if you need continuous scoring, treat that as a separate requirement.
AI agent kill switch
An AI agent kill switch is an emergency control that immediately stops an autonomous agent from taking further action, typically by denying every gated tool call until a human releases it. Pushary provides a kill switch you flip from your phone that blocks all gated actions, including ones your policy would normally auto-approve, until you turn it back off.
The purpose of a kill switch is speed and certainty in a moment when an agent is doing the wrong thing. Rather than finding the terminal, killing a process, or trying to reason with the agent, you want a single control that stops harm now and holds until you decide it is safe to continue. It is the agent equivalent of an emergency stop button on a machine: blunt on purpose.
A meaningful kill switch has two properties. It denies broadly, so nothing slips through while it is engaged, and it is reachable from wherever you are, not only at the machine running the agent. The distinction that matters is between stopping an agent politely, which a determined or looping agent may ignore, and denying its actions at the enforcement layer, which it cannot route around because the tool calls themselves are refused.
A kill switch is one control within a larger safety setup. It handles the emergency case, while standing per-tool policies handle routine gating and an audit trail records what happened before, during, and after you engaged it.
How Pushary relates
Pushary includes a kill switch as part of its human-in-the-loop control layer. When you flip it from your phone, every gated tool call is denied, including the calls your normal policy would auto-approve, so nothing runs until you release it, and the action is recorded in the audit trail. For the full feature, including how it behaves per agent and how to release it, see the dedicated AI agent kill switch page.
Least privilege for AI agents
Least privilege for AI agents means giving an agent only the permissions a task requires and nothing more, so a mistake or a bad instruction has a limited blast radius. Pushary enforces least privilege through per-tool permission policies that default risky actions to denied or human-approved, letting only the actions you have explicitly allowed run on their own.
Least privilege is a foundational security principle: every actor should hold the minimum access needed to do its job. It limits damage, because a compromised or confused actor can only reach what it was granted, and it makes behavior easier to reason about. The principle predates AI, but agents make it urgent because an autonomous agent will use whatever capability it has if a prompt or its own reasoning leads it there.
For agents, least privilege is applied at the level of tools and actions. A read-only task should not carry the ability to delete files or deploy. A local refactor should not silently reach production APIs. The practical way to implement it is deny-by-default: nothing sensitive runs automatically unless it is on an allow list, and everything else is blocked or escalated to a human for a decision. That inverts the risky default where an agent can do anything until stopped.
Least privilege is not a one-time setup. As tasks change, the minimum set of needed permissions changes too, so the allow list and the escalation rules should be reviewed. An audit trail helps here, because seeing what actions agents actually needed tells you where permissions are too broad or too tight.
How Pushary relates
Pushary lets you implement least privilege for coding agents with per-tool permission policies. You decide which tools an agent may call automatically and set the rest to denied or to escalate to you, so the agent operates inside a bounded set of actions rather than with open access. When it tries to step outside that set, the call is blocked or paused for your approval on your phone, and the outcome is logged so you can tighten or loosen the policy over time. The same policies apply across Claude Code, Codex, Cursor, Gemini CLI, Hermes, and MCP agents.
AI agent audit trail
An AI agent audit trail is a durable, tamper-resistant record of what your autonomous agents did and how each sensitive action was decided, including which calls ran automatically, which a human approved, and which were denied. Pushary records every one of these decisions in an append-only trail that cannot be edited after the fact and can be exported, using the same format across every agent you run.
An audit trail answers questions after the fact: what did the agent do, when, and who allowed it. That matters for debugging, for accountability, and for any review or compliance context where an intention is not enough and you need evidence. The defining quality of an audit trail, as opposed to ordinary logs, is that it is durable and hard to alter, so the record can be trusted as a record.
For AI agents the trail should capture decisions, not just outputs. Each gated action is a decision point with an outcome, approved, denied, or auto-handled by policy, and a good trail preserves all three. Append-only design is what gives it integrity: once an interaction is written it is not edited or deleted, so nobody can quietly rewrite history. Being exportable matters too, so the record can live outside the tool and feed reviews or archives.
The trail is also a feedback tool, not only a compliance artifact. Reviewing what agents actually did shows where your policies are too loose, where they nag you needlessly, and where an agent behaved unexpectedly, which feeds directly back into least-privilege tuning.
How Pushary relates
Pushary keeps an append-only audit trail of every agent interaction. Once an action is recorded it cannot be edited or deleted, the one permitted change being writing your answer to it once, and the trail is exportable so it can live beyond the dashboard. Because Pushary sits at the tool-call layer, the same trail covers Claude Code, Codex, Cursor, Hermes, and other agents in one consistent format. For the full feature, including what each entry captures and how export works, see the dedicated AI agent audit trail page.
Human in the loop for AI agents
Human in the loop for AI agents means an autonomous agent pauses at defined moments to get a person's approval before it takes a sensitive action, rather than running end to end unsupervised. Pushary implements this by letting an agent escalate a gated action to you, sending a push notification you can approve or deny from your phone, and only letting the action proceed once you decide.
Human in the loop, often shortened to HITL, is a design pattern where automation does the work but a human retains authority over the decisions that matter. For AI agents it addresses a real gap: agents are capable and fast but can misread intent, hallucinate, or take an irreversible action from a plausible-looking but wrong plan. Keeping a human in the loop puts a checkpoint on exactly the actions where being wrong is expensive.
The pattern only helps if the checkpoint is both enforced and convenient. Enforced means the agent genuinely cannot proceed on a gated action until a human answers, not that it politely asks and continues anyway. Convenient means the human can answer from wherever they are, quickly, because a checkpoint that requires sitting at the terminal does not survive real work. The best setups also let you decide which actions need a human at all, so routine safe work flows and only the consequential calls interrupt you.
Human in the loop pairs naturally with least privilege and an audit trail. Least privilege decides which actions are gated, human approval decides the gated ones in the moment, and the audit trail records how each was decided. Together they turn an unsupervised agent into one that acts freely within bounds and defers to a person at the edges.
How Pushary relates
Pushary is a human-in-the-loop control panel for AI agents. Per-tool policies decide which actions an agent can run on its own and which it must escalate; when it escalates, the agent pauses and you receive a push notification you can approve or deny from your lock screen, so you stay in control without sitting at the terminal. Every decision is written to the audit trail, and the approvals work the same way across Claude Code, Codex, Cursor, Gemini CLI, Hermes, and MCP agents.
Fail-closed approval
A fail-closed approval is a human approval step that treats silence as a no: if nobody answers before the window closes, the guarded action is denied rather than allowed to proceed. Pushary's decisions.ask() works this way by default, reporting anything short of an explicit approval as not approved, so an unattended timeout can never turn into consent.
The terms come from safety engineering. A gate that fails open lets everything through when its mechanism breaks; a gate that fails closed stops traffic until someone fixes it. Applied to agent approvals, the mechanism breaking is not exotic. It is the ordinary case: the person did not see the request in time, the phone was in a pocket, the Slack message scrolled away. A fail-closed design decides in advance that this ordinary case means stop.
An agent that assumes yes on timeout has an approval step in name only. The dangerous path is the quiet one: a message nobody read, a webhook the service missed, and the agent continues into the refund, the deletion, the deployment, or the outbound email. For actions like these, the cost of wrongly proceeding is far higher than the cost of wrongly stopping, which is the asymmetry the fail-closed default encodes.
Implementing it takes more than an if statement. You need a decision primitive that returns a definite outcome (approved, declined, expired), a durable wait that survives restarts so a crash does not lose the pending request, and a record of how each request resolved so you can see later which actions stopped and why.
How Pushary relates
decisions.ask() blocks until a person approves, declines, or answers, and it reports a decline, an expiry, or no answer as not approved. The wait is backed by the durable decisions ledger, so a restart does not lose the request, and every outcome is recorded. The framework adapters for the Vercel AI SDK, LangGraph, CrewAI, Mastra, the OpenAI Agents SDK, Eve, Hermes, and OpenClaw all inherit this default, so a guarded action never runs on silence.
Decision ledger
A decision ledger is a durable, append-only record of every question an agent asked a human and every answer the human gave, kept so the wait can survive restarts and the outcome can be proven later. Pushary writes each decisions.ask() request and its resolution to such a ledger, which is what makes its approvals durable rather than fire-and-forget.
The contrast that defines the term is with a send log. Notification infrastructure records that a message went out and maybe that it was delivered. A decision ledger records a two-sided exchange: what was asked, who it went to, what they decided, and when. The unit is the resolved decision, and the ledger is only complete when the answer, or the fail-closed expiry, is written next to the question.
Durability is the first practical payoff. Because the pending decision lives in the ledger rather than in a process's memory, the agent's wait can be resumed after a crash, a deploy, or a serverless timeout. The agent, or another worker entirely, polls the decision by id and picks up where the wait left off, which is what allows an approval to span minutes or hours without holding a process open.
Accountability is the second. When someone asks who approved the refund at 2am, the ledger is the answer, with the question, the responder, and the timestamp. That record is what turns a human approval feature from a UX nicety into something an engineering lead or a compliance conversation can rely on.
How Pushary relates
Every decision created through decisions.ask() or the decisions API lives in Pushary's append-only ledger. The blocking wait polls it, signed webhooks notify your backend when a decision resolves, and the record is queryable afterwards. The decide page a person answers on can carry your brand, while the underlying record stays intact for audit.
Keyless enrollment
Keyless enrollment is how an end-user of an AI product connects their phone to receive that product's approval requests without creating an account, installing an app, or handling an API key: they tap one link and they are connected. Pushary implements it as enroll(externalId): you pass your own id for the user, they tap the link once, and every later decisions.ask() for that id reaches their phone.
The problem it solves belongs to companies shipping an AI agent to their own users. When the agent needs a specific customer to approve something, that customer has to be reachable on a device they actually carry. Asking every customer to sign up for a third-party service, manage a credential, or install yet another app kills the flow before it starts, so the enrollment step has to cost the user one tap and nothing else.
The mechanics are deliberately one-sided. The company references the user by an externalId from its own user model and calls enroll, which produces a connect link for that user. The user taps it once. Delivery then lands wherever that person actually is: the native app if they have it, PWA push notifications otherwise, and Slack when routed there. The company's id is the only identity involved, so no mapping table or shared secret crosses to the user's side.
The security shape follows from that: the API key stays on the company's server, and the end-user never holds a credential that could leak or need rotating. What the user grants is narrow, the ability to receive and answer that company's decision requests on their phone, and the decide page they answer on carries the company's brand.
How Pushary relates
enroll(externalId) is one call in @pushary/server or pip install pushary, and the returned link is the whole end-user experience: one tap, no account, no app requirement, no key. After that, decisions.ask({ externalId }) reaches that person on their phone, fail-closed and recorded. This pairing is the two-call integration behind Pushary's framework adapters, and it is how a Partner-plan product gives each of its users the final say over their own agent actions.
Human-in-the-loop vs notifications
Human-in-the-loop and notifications solve different problems: a notification tells a person something happened, while human-in-the-loop stops the agent until a person decides something. The test is whether the system blocks on the reply. Pushary ships both on one primitive: notifications for the telling, and decisions.ask() for the deciding, which blocks fail-closed until a real answer comes back.
Sending is one-way. A notification API considers its job done at delivery, and for completion alerts, error pings, and daily digests that is exactly right. A decision is two-way, and its job starts where delivery ends: hold the agent, collect the answer, enforce the timeout, and record the outcome. Mixing the two up is how teams end up with an agent that announced it was about to act instead of asking whether it should.
The confusion is understandable because both begin with a push message to a phone. The difference is everything after the tap. Retrofitting a decision loop onto a send-only API means building the pending-state store, the correlation between question and answer, the timeout policy, the resume path after a restart, and the audit record yourself. That is real distributed-systems work, and it is invisible right up until the first missed approval.
The practical rule: use plain notifications when no action hinges on a reply, and use a decision whenever the agent must not proceed without a person. A refund, a production delete, an outbound email to a customer, a contract step, each of those is a decision even if the message announcing it looks like a notification.
How Pushary relates
One Pushary integration carries both. Completion and error alerts go out as notifications, and the steps that need a person use decisions.ask(), which blocks fail-closed and writes to the durable decisions ledger. Teams usually start with alerts and then add decision gates on their risky tools, without changing platforms, because the delivery, the enrollment, and the audit record are shared.
Common questions
How is an AI agent control plane different from just watching the terminal?
Watching a terminal is manual and only works while you are present. A control plane enforces rules programmatically at the tool-call layer, so risky actions are paused and routed to you for a decision even when you are away from the keyboard, and every outcome is logged.
Does a control plane work across different AI agents?
That is the point of one. A good control plane hooks in at the tool-call or MCP layer so the same policies, approvals, and audit trail apply across agents. Pushary applies its rules across Claude Code, Codex, Cursor, Gemini CLI, Hermes, and MCP agents.
Is a control plane the same as a kill switch?
A kill switch is one feature within a control plane, the emergency stop that denies everything gated until you release it. The control plane also covers standing policies for individual tools, per-action approvals, and the audit record.
Does Pushary support named roles like admin or read-only for agents?
No. Pushary has no documented role-hierarchy feature. It enforces per-tool permission policies that approve, deny, or escalate individual agent actions, which bounds agent behavior without formal roles.
Is per-tool policy the same as RBAC?
Not exactly. RBAC groups permissions under roles that principals inherit. Per-tool policy scopes actions directly to tools or patterns. Both aim to limit what an agent can do, but only true RBAC gives you reusable roles and inheritance.
How do I bound what an AI agent can do without RBAC?
Use deny-by-default per-tool policies so only explicitly allowed actions run automatically and everything else is blocked or sent to a human. That is the least-privilege pattern Pushary enforces at the tool-call layer.
Is AI agent posture management a product or a practice?
Mostly a practice today. It is the ongoing work of keeping agent permissions minimal, approvals enforced, activity logged, and a stop control available. Products like Pushary provide the enforcement pieces rather than a single posture score.
What are the pillars of good agent posture?
Least privilege, enforced human approval on sensitive actions, a durable audit trail, and an emergency stop. Posture is weak whenever any of these exists as intention rather than something actually enforced at the tool-call layer.
Does Pushary give me a posture score?
No. Pushary provides the underlying controls, policies, approvals, audit trail, and kill switch, but does not currently present a posture score or continuous drift report. Evaluate scoring separately if you need it.
What does an AI agent kill switch actually do?
It denies the agent's gated tool calls immediately and keeps denying them until a human turns it off. In Pushary it blocks every gated action, even ones your policy would otherwise auto-approve, so nothing slips through while it is engaged.
Why not just close the terminal or kill the process?
That works only if you are at the machine and can act fast. A kill switch is reachable from your phone and denies at the enforcement layer, so a looping agent cannot route around it while you decide what to do next.
Where can I read the full details of Pushary's kill switch?
See the dedicated AI agent kill switch page at /ai-agent-kill-switch, which covers how it engages, how it behaves per agent, and how you release it.
How do I apply least privilege to a coding agent?
Work deny-by-default. Allow only the specific tools a task needs to run automatically, and set everything else to denied or human-approved. In Pushary this is expressed as per-tool permission policies enforced at the tool-call layer.
Why is least privilege more important for agents than for people?
An autonomous agent will use any capability it holds if its prompt or reasoning leads there, and it acts fast and repeatedly. Bounding its permissions limits how much a single bad instruction or hallucination can do.
Does least privilege slow the agent down?
Only for actions outside the allowed set, which pause for a quick approval. Routine allowed actions run normally. You tune the allow list using the audit trail so common safe actions do not keep prompting you.
How is an audit trail different from a log file?
A log is often mutable and easy to overwrite. An audit trail is durable and append-only, so once an entry is written it cannot be edited or deleted. That integrity is what lets it serve as evidence of what an agent did and who approved it.
What does Pushary's audit trail record?
Every gated decision for your agents: actions that ran automatically under policy, actions a human approved, and actions that were denied. Entries are append-only and exportable, in one consistent format across Claude Code, Codex, Cursor, and Hermes.
Where can I read the full details of Pushary's audit trail?
See the dedicated AI agent audit trail page at /ai-agent-audit-trail, which covers what each entry captures, the append-only guarantee, and how export works.
What does human in the loop mean for an AI agent?
The agent does the work but pauses at defined points to get a person's approval before a sensitive action. In Pushary the agent escalates the gated call, you get a push notification, and it proceeds only after you approve or deny.
Does keeping a human in the loop mean approving everything?
No. You choose which actions require a human using per-tool policies. Routine safe actions run automatically, and only the consequential or risky ones pause for your decision, so you are not flooded with prompts.
Do I have to be at my computer to answer?
No. Pushary sends approvals to your phone as push notifications you can answer from your lock screen, which is what makes the checkpoint survive real work instead of stalling the agent whenever you step away.
What does fail-closed mean in an AI agent approval?
If nobody answers before the window closes, the decision is treated as denied and the agent does not take the guarded action. Silence, a missed notification, or a crash all resolve to no rather than yes.
Why is fail-open dangerous for agent approvals?
Because the failure case is ordinary: someone did not see the request in time. A fail-open gate turns every missed notification into consent, which for refunds, deletions, and deployments is exactly the wrong default.
How does Pushary implement fail-closed approvals?
decisions.ask() returns a definite outcome and reports anything short of an explicit approval as not approved. The pending request lives in a durable ledger, so restarts do not lose it, and every resolution is recorded.
How is a decision ledger different from a notification log?
A notification log records sends. A decision ledger records the full exchange: the question, the person, the answer or fail-closed expiry, and the timing. The unit is a resolved decision, which a send log never captures.
Is the decision ledger what makes the wait durable?
Yes. The pending decision lives in the ledger, so a crash, a deploy, or a serverless timeout does not lose it. Any process can poll the decision by id and resume the wait.
Can I query or export the decisions afterwards?
Yes. Decisions are stored durably and are readable through the API, and signed webhooks push each resolution to your backend as it happens, so your own systems can keep their own copy.
Does my end-user need a Pushary account or app?
No. They tap one link to connect their phone. Native app push is used when they have the app, PWA push notifications otherwise, and there is never an account, a bill, or a key on their side.
What id do I use for enrollment?
Your own. externalId is whatever your user model already calls this person. Pushary maps it to their connected phone, so your code never handles a second identity system.
What happens if I ask a user who never enrolled?
Nobody receives the question, so the decision resolves as not approved when the window closes. That is the fail-closed default protecting you, but the real fix is to enroll the user before the first ask.
Is a push notification enough for an AI agent approval?
No. A notification only delivers the message. An approval needs the agent held open, the answer collected, a fail-closed timeout, and a record of the outcome, which is what a decision primitive like decisions.ask() adds.
What breaks if I build approvals on a send-only API?
You inherit the pending-state store, question-to-answer correlation, timeout policy, restart recovery, and audit log as your own distributed-systems project. The failure mode is silent: a missed message quietly becomes a missed approval.
Can Pushary send plain notifications too?
Yes. The same integration sends completion and error alerts, and the same delivery path (native app push, PWA push notifications, Slack) carries them. Decisions add the blocking wait and the ledger on top.
Put the vocabulary to work
Pushary is the control plane these terms describe: one permission policy, phone approvals, a kill switch, and an immutable audit trail across Claude Code, Codex, Cursor, Gemini CLI, and any MCP agent.