The best way to govern actions taken by AI agents is to enforce authorization and policy before each action executes. Give agents distinct identities, limit their access to what they need, require approval for sensitive operations, and record whose authority was used and what happened.
These controls should operate outside the model. An agent can propose an action, but a trusted system should decide whether it is permitted.
For agents acting on behalf of people, governance must answer three questions on every request: Which agent is acting? Who is it acting for? Is this specific action allowed?
What does it mean to govern an agent’s actions?
An agent that summarizes a document produces an answer. An agent that sends an email, issues a refund, or changes a production system exercises authority.
Governing that authority means defining which systems it can access, which operations it can perform, when human approval is necessary, and how access can be withdrawn.
Broader AI governance also includes ownership, evaluations, monitoring, and incident response. This article focuses on the controls between an agent’s proposed action and its execution against a connected system.
That boundary matters because an agent can select a legitimate tool and still use it inappropriately. OWASP identifies excessive functionality, excessive permissions, and excessive autonomy as causes of excessive agency: damaging actions resulting from unexpected or manipulated model outputs. OWASP’s guidance on excessive agency provides a useful foundation for designing these controls.
Start with identity and explicit authority
An agent needs its own identity so its access can be scoped, audited, and revoked independently.
When it acts for a person, that agent identity should be connected to an explicit delegation. Authenticating a user establishes who they are; it does not establish everything an agent may do with their access.
For example, a support representative might be authorized to issue refunds up to $2,000 while delegating only refunds up to $100 to an agent.
The distinction is straightforward:
User authority: What the person is permitted to do.
Delegated authority: What that person has authorized this agent to do.
Runtime policy: The additional conditions that apply to a particular action.
For delegated actions, the agent’s effective permissions should remain within all applicable boundaries. Human approval should not grant authority that the user or agent never possessed.
Enforce policies on the actual request
OAuth scopes and application roles establish useful access boundaries. Business rules often require more detail.
An agent may need permission to send email, but only to internal recipients. It may need to create refunds, but only below a threshold. It may need access to a production database, but only for approved read operations.
Evaluate the proposed operation and its relevant parameters before execution. Depending on the workflow, that can include the destination, resource, amount, HTTP method, endpoint, or approval status.
Prompt instructions still help the agent choose appropriate actions. Enforcement determines whether an inappropriate choice can reach the connected system.
The enforcement boundary also needs to be complete. If the agent can bypass a governed tool and use an unrestricted credential directly, the policy does not reliably constrain its actions.
Use approvals where human judgment matters
Requiring approval for every action can make an agent impractical. Allowing every action automatically gives it unnecessary autonomy.
Define which operations can proceed automatically, which require review, and which are prohibited.
Consider this illustrative refund policy:
Proposed actionDecisionRefund $75 on an eligible orderAllow automaticallyRefund $350Require approval from an authorized representativeRefund $2,500Deny because it exceeds the representative’s $2,000 limitRefund through another employee’s accountDeny unless a valid authorization path exists
Approval should apply to a specific action. If the amount, recipient, or other material details change, the original approval should not silently authorize the changed request.
Contextual risk assessments can help identify unusual activity. Hard authorization boundaries should still apply regardless of a risk score.
Separate organization policy from user limits
Organizations and end users have different responsibilities.
An organization might prohibit external sharing, require approval for payments above a threshold, or restrict access to production systems.
An end user might allow a particular assistant to read their calendar while requiring approval before creating events. Another user might authorize the same assistant to schedule meetings automatically.
User limits should be able to narrow delegated access within the organization’s boundaries. They should not override an organization’s prohibition.
This becomes especially important when one agent serves an entire team. A shared agent does not imply shared authority: each request still needs the correct account, delegation, and applicable policies.
Keep credentials outside the agent runtime
Where possible, let the agent request an operation through a trusted execution layer that holds and uses the provider credentials.
This reduces credential exposure and creates a place to enforce policy before the downstream request.
Credential protection and action authorization address different problems. A hidden token can still be used to perform an overly broad action unless the request itself is checked.
For the same reason, sandboxing complements access controls. A sandbox constrains the agent’s execution environment; authorization constrains what it may do to connected systems.
Make actions attributable and access revocable
An audit record should let an administrator answer:
Which agent acted, and on whose behalf?
What operation did it request?
Was it allowed, denied, or held for approval?
Who approved it, if approval was required?
What outcome did the connected system return?
Users should also be able to understand what agents have done with their delegated access.
Provide a way to revoke access promptly, and check revocation on subsequent requests. Test denied requests, expired access, changed approval parameters, and attempted bypasses alongside successful workflows.
How Alter implements these controls
Alter provides an access layer for governing agent actions against connected systems.
Agents can receive scoped access through delegated grants. Runtime policies can constrain operations and parameters, and sensitive requests can require human approval. Alter evaluates applicable rules across the delegation chain; a denial at any level wins. See the guides to scoped agent access and runtime policies.
For calls routed through Alter, provider credentials can remain in its vault while the agent requests authorized operations. This model depends on routing governed actions through Alter and preventing alternative access paths.
The end-user Wallet provides visibility into connected accounts and delegated access, including controls to revoke delegations. Users can also see the audit activity concerning their own grants. Administrators have broader application-level visibility. See the Wallet documentation and audit log documentation.
A useful first implementation is one agent, one connected system, and three test cases: an action that succeeds automatically, one that requires approval, and one that is denied.
You can try Alter, explore the documentation, or book a conversation to work through your first integration.