Giving an AI agent access to tools also gives it a route to act. The organization operating it needs to define that authority, set its limits and establish how those limits are enforced.
An agent might read an invoice in one system, look up a supplier in another and submit a payment through a third. Each system can authenticate the request. The company operating the agent must also establish who authorized that workflow, what limits apply and where those limits take effect.
Our governance map organizes that work into 12 requirements, from agent identity through testing, incident response and supplier oversight. R means requirement: R1 is Requirement 1, R2 is Requirement 2, and so on. These are labels in our engineering checklist, rather than references to a regulation or an official standard.
The work starts with two foundations: map the agent's effective authority, then translate its business mandate into policy. These are Requirements 1 and 2. They give the remaining controls a defined scope and something concrete to test. They are also the starting point for AGIS, the governance layer we are building to connect business mandates to execution controls and evidence.
Requirement 1: Map the agent's authority
An inventory entry is a starting point. An authority map should connect that entry to the systems and permissions that make action possible.
For each workflow, the team should record:
- The business owner and the identity under which the agent acts.
- The tools, credentials and data the agent can reach, including shared service accounts.
- The actions those tools can perform and the approval checks on each route.
- Any delegation to another agent, direct API access or queued work that extends the workflow.
The map should distinguish observed access from assumptions and unknowns. An agent's own identity may be read-only while a connected service holds write credentials. A tool named “prepare payment” may create a proposal or submit an instruction. Those differences change the control the organization needs.
This also changes how teams investigate risk. They can trace an untrusted input through the tools it can influence to an action with a business consequence. The result is a defined assessment scope, including routes that need further investigation.
Requirement 2: Translate the business mandate into policy
The business owner should state the agent's purpose and limits in language they can review. “Process supplier invoices” leaves important decisions open: which suppliers qualify, who can change payment details and when a person must approve an exception.
A useful policy connects each mandate clause to:
- The action and data it permits.
- The conditions that must hold before execution.
- The system responsible for enforcing those conditions.
- The response when evidence is missing or an exception requires approval.
Plain-language policy generation can help with this translation. Generated rules still need review against the mandate, available tool parameters and actual execution paths. A rule that depends on information the enforcement point cannot see needs another control or a narrower delegation.
Hard limits should use authoritative state. A spending cap, for example, needs consistent accounting across the actions it covers. A judgment about whether an action serves the business purpose may require context. Teams should specify how those judgments interact with hard constraints and when uncertainty sends an action to a person.
Connect the agent's authority to the business owner's rules
Requirements 3–5: Check an action before it happens
Requirement 3 sets hard money limits. An agent that can move money needs payment, beneficiary and aggregate spending limits enforced outside the model. The accounting must cover concurrent requests and retries, so individually permitted payments cannot together exceed the budget. Cloud authorization can constrain a tool call; the payment or ledger system must also account for what has already been committed.
Requirement 4 checks whether an action serves the mandate. An action can fit an amount limit while serving the wrong purpose. A document might steer an agent from preparing an invoice to sending a payment. Semantic checks assess the proposed action in context. Teams need to test both missed attacks and legitimate actions blocked by mistake, with explicit rules for uncertainty and escalation.
Requirement 5 makes human approval specific and enforceable. When policy requires a person's approval, they should see exactly what the agent proposes to do. Approving a payment means approving that recipient, account and amount—not giving the agent general permission to move money. Material changes require fresh approval, and the same approval cannot authorize a second payment. If approval is denied, expires or never arrives, the action must not proceed.
Apply different checks to the same proposed action
Requirement 6: Test the workflow that will actually run
Pre-deployment testing should cover the deployed combination of model, instructions, tools and policy. Testing a prompt alone leaves the effects of credentials, application logic and downstream services unexplored.
Useful scenarios include untrusted instructions in a tool response, an outage after a payment has been accepted, and an alternative route around the usual control. Ordinary permitted actions belong in the same test set. A control that stops every action also stops the workflow from doing its job.
Each finding should lead to a correction and a repeatable check of the result. Changes to the model, tool access or mandate should trigger review of the affected tests. R1 identifies the paths to exercise; R2 supplies the rules that define a passing result.
Connect a finding to a repeatable check of the fix
Requirements 7 and 8: Make decisions reviewable
Requirement 7 preserves a trustworthy action record. Reviewers should be able to connect the acting identity, mandate version, proposed action, approval, policy decision and downstream result. The record needs protection against alteration and deletion. Teams also need to detect missing events: protecting the logs that arrived does not establish that every committed action was logged.
Requirement 8 supports model-risk review. The organization needs an account of the agent's intended use, limits, validation results, changes and remaining risks. An independent reviewer should be able to reconstruct why a particular configuration was allowed to operate and which exceptions remain open. Provider assurance reports can inform that review within their stated scope; they do not establish that the organization's complete agent workflow is safe.
Give reviewers a traceable basis for the operating decision
Requirement 9: Test withdrawal of authority
Stopping an agent process is only part of an incident response. Delegated credentials may still work, queued jobs may remain active and a downstream service may already have accepted an instruction.
The stop procedure should cover those routes and measure how long withdrawal takes to reach them. Teams should test a stop during an active call, a queued job and an approval pause. They also need to reconcile actions already committed. A stop cannot be assumed to reverse a completed payment.
This is another practical use of the authority map: it tells operators which identities, credentials and services the procedure must reach.
Verify that withdrawal reaches every route to action
Requirement 10: Keep supplier oversight with the organization
An agent workflow can depend on a model provider, cloud platform, tool server and payment or data service. Supplier oversight should establish what each party controls, how it handles sensitive data and what happens when its service changes or fails.
Procurement, legal and security teams retain responsibility for contracts, assurance scope, resilience and exit options. Technical findings from an authority map can inform that work by identifying the dependencies in use. TestMachine's intended product scope excludes R10; it remains part of the governance picture an organization needs to address.
Use the dependency map to inform supplier review
Requirements 11 and 12: Preserve boundaries across systems
Requirement 11 carries authority through delegation. Delegation can send work to another agent or a tool on another platform. The receiving system should enforce the original mandate's limits. Delegation must not turn read-only authority into permission to write. Protocol compatibility makes communication possible; each receiving endpoint still needs authorization checks and a linked record of who acted for whom.
Requirement 12 connects explanations to permitted data use. An operator should be able to trace a decision to the relevant mandate clause and supporting evidence. Access and retention rules must also govern the data used to make that decision. An explanation for an end user should avoid disclosing confidential policy or another customer's information.
Together, these requirements keep the business mandate relevant when a workflow crosses technical and organizational boundaries. They also make changes easier to assess: a new tool, delegated agent or data source creates a specific set of permissions, tests and records to review.
Preserve the mandate and data boundaries across a handoff
Where cloud-provider controls fit
The requirements describe what a governed workflow needs. Cloud platforms supply many of the controls that can help meet them. The environment already includes more than model guardrails:
- AWS AgentCore Policy supports plain-language policy authoring, generates candidate Cedar policies and validates them. It evaluates tool requests passing through AgentCore Gateway before allowing access. AWS documentation
- Google's Agent Gateway brings together agent identity, registered destinations and access policies. Its documented policy options include semantic governance and delegated authorization. The available checks depend on the runtime, protocol and traffic direction. Google documentation
- Microsoft Agent 365 provides a centralized agent registry and connects lifecycle governance with Entra, Purview and Defender. Availability depends on licensing and the relevant integrations. Microsoft documentation
- Cloudflare MCP portals let administrators curate tool access and log requests through a shared endpoint. Cloudflare explicitly warns that direct upstream access can bypass portal policies unless the server itself is protected. Cloudflare documentation
These capabilities are useful places to apply controls. An organization still needs to define which actions fall under those controls and how they relate to its business rules. A gateway check covers the traffic routed through it. A policy can enforce the conditions it represents. Both boundaries matter when assembling a complete workflow.
The full map below puts those documented controls alongside AGIS's intended scope. It shows where native mechanisms contribute and where integration or further evidence is needed. The AGIS column describes our product direction across 11 of the 12 requirements; it is separate from the cloud coverage ratings.
The full map compares cloud controls and intended AGIS scope
An invoice workflow makes the distinction concrete
Consider an illustrative agent that prepares supplier payments. Its mandate allows payments to verified suppliers within an approved budget. Changed bank details require independent verification.
R1 traces the route. The team maps invoice intake, supplier records, payment credentials and the submission API. It checks whether the agent can change a supplier record as well as initiate a payment, including through another service.
R2 defines the conditions. The policy requires verification of the specific payment destination before submission. It identifies the trusted verification record, the budget authority and the approval needed for exceptions. Text inside an invoice cannot grant an exception.
Testing checks the connection. The team tries an ordinary approved payment and an invoice containing new bank details. It also checks a route that bypasses the normal submission tool. The expected result is that the changed destination cannot receive a payment until verification is recorded on every available route.
The wider controls make that rule operational. Budget checks cover simultaneous payment requests. An approval is tied to the verified destination. The action record links that decision to the payment result, and the stop procedure reaches any payment job still waiting to run. A delegated service must preserve the same verification requirement.
That is a proposed test, not a reported customer result. It illustrates why discovering a route and defining a rule must lead to a check at the point where the action takes effect.
AGIS connects the mandate to execution controls
AGIS is being built as the governance layer between an organization's business mandate and the controls that govern execution. The business owner defines acceptable behavior. Native cloud services, applications and downstream systems provide the identities, authorization checks, ledgers and records through which actions happen.
Our focus starts with Requirements 1 and 2: understanding an agent's tools, permissions and dependencies, then connecting its business mandate to readable policies and explicit controls. The broader AGIS direction keeps that mandate connected to testing, enforcement decisions, approvals and evidence across those systems. It builds on native controls while preserving authoritative budget state, payment-system responsibilities and the organization's risk decisions.
Our intended AGIS scope covers 11 of the 12 requirements in the map. Requirement 10, vendor oversight, is the sole exclusion. This describes product scope rather than completed coverage or a release commitment.
AGIS connects the business mandate to execution controls and evidence