AI Agent Governance: The Control Plane

Governance controls four things: which systems an agent can reach, which actions it can take inside them, which of those actions require a human decision before they execute, and what gets recorded about each one. Everything else that gets called governance, policies, principles, review boards, is upstream of those four and only matters once it is expressed as one of them. Reach is controlled by identity. An agent that updates Salesforce after a call holds credentials that are its own, scoped to the objects and fields that workflow needs and nothing more. Action is controlled by the tool surface the agent is given. If the agent has no tool that deletes records, it cannot delete records, regardless of what it is asked. Decision is controlled by the approval gate, which classifies each proposed action as automatic or gated and holds the gated ones until a named person approves, edits, or rejects. Record is controlled by the audit trail, which captures the proposal, the approver, the timestamp, and the outcome in the target system. Notice what is not on the list. Governance does not control the model's reasoning, its tone, or the quality of its drafts. Those are product concerns. A governance layer assumes the agent will sometimes propose the wrong thing and makes sure the wrong thing does not reach a customer record, a ticket queue, or an inbox without a person seeing it first. In ASTRA that is the whole design: the agent drafts, the Review Console shows the draft, a human decides, the connector executes, the trail records.

A control plane is the layer that sits between the agent that decides and the systems that change state. The agent never holds a direct write path. It emits a proposed action, structured as a target system, an operation, the fields involved, and the evidence it is acting on, which in post-call execution is the transcript span that contains the commitment. The control plane receives that proposal and runs it through three stages before anything is written. The first stage is identity resolution. The proposal is matched to the agent that produced it and to the scoped credential that agent is permitted to use. If no scope covers the operation, the proposal is rejected here and logged. The second stage is classification. Each proposal is checked against the approval policy for that action type. Reads and low-consequence writes, such as logging a call summary, can pass automatically. Consequential writes, such as changing a close date, opening a ticket in a customer's name, or sending an email, are held for review. The policy is a table the operator edits, not a prompt. The third stage is execution and verification. When a held action is approved, the connector performs it with the agent's scoped credential, then reads the target back to confirm the write landed as intended. The result, including any mismatch, is appended to the trail. Kill switches live in the control plane too. Disabling an agent revokes its scoped credential and drains its pending proposals. Because every write passed through the plane, there is no side channel to cut.

Guardrails shape what the model produces. Governance decides what happens to what it produced. They are often confused because both are described as keeping the agent safe, but they live in different places and fail in different ways. A guardrail is typically a filter on input or output: block certain topics, refuse certain instructions, check a draft against a rubric before returning it. It runs inside or beside the model call. It is probabilistic in practice, because it depends on the model or a classifier recognising the case, and it can be bypassed by inputs that were not anticipated, including prompt injection through a transcript or a web page the agent reads. Governance is deterministic. Scoped identity is enforced by the target system's permission model. The approval gate is enforced by the control plane refusing to execute an unapproved action. The audit trail is written whether or not the model cooperated. None of that depends on the model behaving. The practical consequence is that guardrails reduce how often the agent proposes something wrong, and governance bounds the damage when it does. You want both, but if you have to choose which to build first, build governance. A well-governed agent with weak guardrails produces drafts a human rejects. A well-guarded agent with no governance produces a correct draft most of the time and an unrecoverable write the rest of the time. Excessive agency, the condition where an agent can do more than the task needs, is a governance gap, and no amount of prompt engineering closes it.

An agent inventory is a register of every agent that can act on your systems: what it is, which workflow it serves, which identity it uses, which systems it can write to, which of its actions are gated, and who owns it. It is the first control surface because every other control refers to it. You cannot scope an identity for an agent you have not named. You cannot audit an action back to a workflow that is not registered. Inventories drift in a predictable way. The first agents are added deliberately. Then an integration ships with an agent inside it, a team member connects a tool to the CRM, a vendor adds an automation to a product you already use. Each of these can write to a system of record. None of them appear in the register unless something forces it. The forcing function is identity. If the only credentials that can write to the CRM are the scoped, per-agent credentials the control plane issues, then an agent that is not in the inventory has no credential and cannot write. The inventory stops being a document someone maintains and becomes a side effect of how access is granted. For each entry, the fields that matter operationally are: the owner who can approve its actions, the scope it holds, the action types classified as gated, the date it was last reviewed, and its current state, active or disabled. In ASTRA each registered agent maps to one scoped identity in each connected system, so the inventory and the permission model are the same list viewed two ways.

Agent-aware governance means the control plane knows which agent is acting, not just which user account the agent borrowed. Most existing governance in a GTM stack is user-aware: Salesforce knows a change was made by a user, the email system knows a message was sent from an address, the ticketing system knows a ticket was opened by a login. When an agent acts through a human's session or a shared integration user, those systems record the human or the integration, and the agent disappears from the record. The practical test is simple. Pick any change an agent made last week and ask the system of record who made it. If the answer is a person's name or a generic integration user, governance is not agent-aware. If the answer is the agent's own identity, it is. Agent-aware governance needs three things to hold. The agent has its own identity in each target system, so the system's native audit shows the agent. The control plane records the human approver alongside the agent, so the trail shows both who proposed and who authorised. And the scope of that identity is narrower than any human's, so a compromised or misbehaving agent cannot do what its owner could do. This is also what makes the trail usable during an incident. When a customer asks why their renewal date moved, the answer is an agent name, a proposal, an approver, and a transcript span, retrieved in one lookup. Without agent awareness the same question becomes a search through a human's activity history for a change they do not remember making.

Auditing governance means testing whether the controls hold, not reading the policy that says they should. Four checks cover most of it. Scope check. For each agent in the inventory, list the permissions its identity actually holds in each target system and compare them to what its workflow needs. Anything it holds but does not use is excess. Try the excess: attempt a write outside the intended scope using the agent's credential and confirm the target system refuses it. Gate check. Take the approval policy table and, for each action type marked gated, attempt that action through the agent and confirm it is held rather than executed. Then reject it and confirm nothing was written. Then approve one and confirm the trail shows the approver, the timestamp, and the verified result. Trail check. Pick a sample of writes in each target system's native audit log and trace each one back to a proposal in the control plane. Any write that has no matching proposal came through a path the control plane does not cover. That is the finding that matters most, because it means the agent, or something else, has a write path you did not know about. Kill check. Disable an agent and confirm its credential is revoked in every system it was connected to, that its pending proposals are drained, and that a new proposal from it is rejected. Run these on a schedule and after any change to scopes, policies, or connectors. The audit trail itself should be retained long enough that the trail check can cover the whole period since the last audit.

Ownership splits along the same lines as the control surfaces. Someone owns the inventory and the approval policy. Someone owns each agent and approves its gated actions. Someone owns the platform permissions the identities depend on. These are usually different people, and confusion about which is which is a common cause of governance existing on paper but not in the system. The approval policy belongs to the team whose customers are affected. For post-call execution that is the customer success or account management lead, because they are accountable for what gets promised and delivered. They decide which action types are gated and who is allowed to approve them. Per-agent ownership belongs to the person whose work the agent does. A CSM who ran the call approves the actions drafted from it, because they are the one who knows whether the drafted ticket matches what was actually agreed. Routing approvals to someone who was not on the call defeats the gate; they approve on trust, which is the same as no gate. Platform permissions belong to whoever administers the CRM, the ticketing system, and the email domain. They provision the scoped identities and can revoke them. Governance depends on this team refusing to issue broad credentials for convenience. Security or IT should own the audit, meaning the periodic checks described above, and should have read access to the trail without needing to ask. What they should not own is day-to-day approval. If every consequential action routes to a security queue, the queue becomes the bottleneck and approvals become rubber stamps.

Governance fails quietly, which is why it has to be checked. The failure modes below are the ones that show up in practice. Shared credentials. The agent acts through a human's login or a single integration user. Scope cannot be narrowed without affecting the human, the trail shows the wrong actor, and disabling the agent means disabling the person. Approval fatigue. Too many action types are gated, or the same low-risk action is gated repeatedly, and approvers stop reading. The gate still exists but no longer functions. The fix is to move low-consequence, reversible actions to automatic and keep the gate for writes that reach a customer or change a commitment. Approval without context. The approver sees the proposed action but not the evidence it came from. They cannot judge whether a drafted ticket matches the call, so they approve or reject on instinct. The proposal must carry its source, in post-call execution the transcript span, into the review surface. Unverified writes. The connector reports success without reading the target back. Field mappings drift, validation rules change, and the trail records writes that did not land or landed wrong. Uncovered write paths. An agent or integration writes to a system of record without passing through the control plane. The trail check above is how you find these. Inventory drift. Agents exist that no one registered. Identity-gated access is the structural fix. Injection through the agent's inputs. A transcript or document the agent reads contains instructions. The approval gate is the control that catches this, because a person sees the resulting proposal before it executes. This is why the gate cannot be bypassed for actions the agent considers routine. The agent's own confidence is not a signal the control plane should trust.

Start with the write paths, because that is where governance either holds or does not. List every system of record an agent can change: the CRM, the ticketing system, email, chat. For each, find out which credential the agent uses and whether that credential belongs to the agent alone. If the answer is a shared or human credential, fix that before anything else. Provision a scoped identity per agent per system, with permissions limited to the objects and fields the workflow touches. This single change gives you an inventory, a working kill switch, and an honest audit log in the target system, without building anything new. Second, put an approval gate in front of every write that reaches a customer or changes a commitment. Do not try to classify every action on day one. Gate everything consequential, run it for a while, and move actions to automatic only when the review history shows they are consistently approved unchanged. Third, make sure the trail records the proposal, the evidence, the approver, and the verified result, and that someone outside the approving team can read it. Then run the four audit checks and fix whatever they find. Only after that is it worth spending time on policy documents, frameworks, and vendor evaluations, because by then you will know what the controls need to enforce. ASTRA implements this sequence as its default configuration: scoped identities in Salesforce, HubSpot, Jira, Gmail, and Slack, a gate in the Review Console in front of every consequential write, and a trail that ties each write back to the call it came from.