ACP, or Agent Control Protocol, explained

The control problem

Agentic AI systems can plan and use tools, which means they can eventually affect real systems. That creates a control problem. It is not enough for an agent to decide that an action is useful. The system must decide whether the agent is authorized, whether the action is within scope, whether policy allows it, and whether a human approval is required.

ACP-style thinking puts an admission layer between agent intent and system mutation. The agent may propose an action, but the control layer checks identity, capability, delegation, environment, and policy before execution.

Core concepts

• Agent identity: which agent or workflow is requesting action.
• Intent: what the agent wants to do and why.
• Capability scope: what the agent is allowed to access or change.
• Policy: rules that determine whether an action is permitted.
• Admission check: the decision point before execution.
• Approval: human or automated authorization for sensitive actions.
• Audit trail: a record of request, decision, execution, and outcome.

Why ACP matters for agentic AI

As agents get more capable, the safety question shifts from "can the model answer correctly?" to "should this action be allowed right now?" A correct action can still be unauthorized, poorly timed, too risky, or outside the user's intent.

ACP-style controls are especially relevant for cloud operations, deployments, billing, IAM, data access, procurement, messaging, and any workflow where an agent can affect external state.

Policy dimensions

A control layer can evaluate several dimensions before admitting an action. Identity asks who or what is requesting the action. Capability asks whether that agent is allowed to perform the action. Scope asks whether the target system, account, repository, project, or environment is allowed. Context asks whether the action is appropriate given the task and risk. Approval asks whether a human or higher-level policy must confirm the action.

This matters because permission is not binary. An agent may be allowed to read production logs but not deploy. It may be allowed to create a draft pull request but not merge it. It may be allowed to update a sandbox environment but not production.

Human approval is one control, not the only control

Human approval is important, but a mature control model can include automated checks too. The system might block actions outside business hours, reject changes without rollback plans, require two approvals for IAM changes, or allow low-risk sandbox actions automatically.

The key is that the agent's intent becomes inspectable before execution. The system can ask: what is being changed, why, by whom, under which delegation, against which environment, and with what recovery path?

Audit and accountability

Agent control is also about records. If an agent changes a system, the organization needs to know what was requested, what policy decision was made, who approved it, what executed, and what happened afterward. This is especially important in regulated environments or production operations.

An audit trail should connect the original user request to the agent plan, proposed action, control decision, execution result, and final artifact. That trace helps teams debug failures and prove that workflows followed policy.

ACP vs MCP vs A2A

MCP helps agents connect to tools and resources. A2A helps agents communicate with other agents. ACP-style control focuses on whether an action should be admitted before it changes a system. These are complementary layers, not replacements for each other.

A cloud agent might use MCP to inspect resources, communicate with another agent through A2A, and then pass a proposed remediation through an ACP-style control layer before execution.

Example control flow

1. The agent proposes an action: update a production configuration value.
2. The host captures intent, target environment, expected change, and risk summary.
3. The control layer checks whether the agent has permission to request that action.
4. Policy determines that production config changes require human approval.
5. The user reviews the proposed change, rollback plan, and evidence.
6. If approved, the system executes and records the outcome.

This flow makes agent execution more reviewable. It also creates a record that can be audited later.

ACP in Kendr terms

Kendr already emphasizes approval-aware workflows. A skill pack can mark risky actions, an MCP integration can expose tools, and the product can ask for approval before side-effecting work. ACP is a useful conceptual lens for this: treat risky agent actions as requests that must pass a control boundary.

Continue with agentic AI systems explained or cloud operations AI assistants.

Frequently asked ACP questions

Is ACP the same as permissions?

No. Permissions are part of the picture, but ACP-style control is broader. It considers identity, intent, scope, policy, delegation, approval, and auditability before execution.

Does every agent action need admission control?

No. Reading public documentation or drafting a summary does not need the same control as changing IAM, deploying code, deleting data, or sending a message externally. The control model should match risk.

What is the practical benefit?

The benefit is confidence. Teams can let agents get closer to real workflows when they know risky actions must pass policy and approval before changing state.

How to apply ACP thinking

List the actions your agents might take, then group them by risk. Reading docs, summarizing logs, and drafting plans can usually be low risk. Sending messages, changing tickets, writing files, deploying code, modifying cloud resources, and touching sensitive data need stronger controls.

Once actions are grouped, decide which require approval, which require logging, which require scoped credentials, and which should be unavailable to agents entirely.