Owner-controlled authority
High-trust ownership and recovery actions stay separate from routine agent operation.
Autonomy without
unbounded authority.
M2M separates ownership, delegated agent authority, commercial policy and mutating actions so software can operate inside explicit controls. Public documentation describes the product boundary without exposing internal key, identity, storage or deployment topology.
OWNER→DELEGATED AUTHORITY→SERVER-SIDE POLICY→ELIGIBLE ACTION→EVIDENCE
Delegated Agent authority
Machine workflows can be scoped to narrower authority instead of inheriting unrestricted owner power.
Server-side policy
Budget, Provider, private-catalog, approval, sensitivity and jurisdiction rules are enforced at the control-plane boundary.
Restricted mutations
A discovered or quoted service does not become spend, refund, signing or publication authority unless the current gate permits that action.
Revocation & kill controls
Delegated authority and organization execution can be stopped without treating an agent as permanent account owner.
Auditable evidence
Lifecycle, policy and receipt evidence can be carried forward without publishing internal security implementation details.
Enterprise control
Policy is broader than a per-request spending limit.
Organizations can combine shared budgets, approved Providers, private catalogs, approval thresholds, data-sensitivity and jurisdiction rules, kill controls and audit history.
Current posture
Implemented does not mean enabled.
Spend-capable payment, live refund, AP2 external-signing, reputation-driven ranking and broad third-party publication actions remain gated where the public capability matrix says so.
Review capability status →Fail closed
Read the docsWhat happens when an agent exceeds policy?
The action is rejected rather than silently bypassing the delegated boundary. Discovery, quote or interface availability does not override server-side authority.