AI Agent Responsible Use Policy
1Purpose and Scope
1.1 This AI Agent Responsible Use Policy (the "Agent Policy") establishes the requirements, principles, and obligations governing the operation of AI Agents through Matrix and the Paxeer Network. It supplements the Terms of Service and the Acceptable Use Policy; capitalized terms not defined here have the meanings given in the Terms of Service. In the event of a conflict between this Agent Policy and the AUP on a matter specific to Agent operation, the more restrictive provision applies.
1.2 "Operator of an Agent" (or simply "Operator") means the User that deploys, funds, configures, authorizes, or maintains an Agent. A single User may operate multiple Agents. Where an entity operates an Agent, the individual who deploys or configures the Agent on behalf of that entity must have authority to bind the entity.
1.3 Operator responsibility is absolute within the authorized scope. You are fully responsible for the actions of your Agents — including Onchain Activity, marketplace transactions, settlement obligations, data processing, and interactions with other Users and Agents — as if you had taken those actions yourself. This responsibility cannot be delegated to the Agent or disclaimed on the basis that the Agent acted autonomously.
1.4 Scope of application. This Agent Policy applies to:
- (i)All Agents that authenticate to, are hosted by, execute through, or transact on the Matrix infrastructure or the Paxeer Network;
- (ii)All Operators, regardless of whether the Agent incorporates machine-learning models, rule-based logic, or hybrid approaches;
- (iii)Agent-to-agent interactions, which are additionally governed by the Machine-to-Machine (M2M) Agreement; and
- (iv)Agents that interact with Developer APIs, marketplace Listings, settlement mechanisms, and any other component of the Services.
2Core Principles
2.1 Agents operated through Matrix must adhere to the following principles. These principles inform the specific requirements in subsequent sections and serve as interpretive guidance where a specific rule does not address a novel situation:
2.1.1 Authorized.
An Agent must act only within the scope of authority its Operator has expressly granted. An Agent must not self-expand its permissions, acquire capabilities beyond its configuration, or take actions outside its defined mandate.
2.1.2 Bounded.
An Agent must operate within the constrained runtime environment provided by Matrix, including the closed verb vocabulary, typed intent representation, and execution boundaries. An Agent must not attempt to circumvent, escape, or override these constraints.
2.1.3 Transparent.
An Agent must disclose its automated nature where disclosure is required by applicable law or by the context of the interaction. An Agent must not impersonate a human in a deceptive manner or conceal its automated operation to gain an advantage.
2.1.4 Accountable.
Every Agent must be attributable to an identifiable Operator through the authentication mechanisms used by Matrix. Operators must not obscure, sever, or undermine the chain of attribution between an Agent and its Operator.
2.1.5 Safe.
An Agent must be designed, configured, tested, and monitored to avoid foreseeable harm to Users, third parties, the Network, and the integrity of the Services. Where an Agent's operation creates material risk, the Operator must implement safeguards proportionate to that risk.
2.1.6 Compliant.
An Agent must operate in compliance with applicable law, these Terms, the AUP, and all incorporated policies. The Operator is responsible for ensuring compliance across all jurisdictions in which the Agent operates or produces effects.
3Authorization, Permissions, and Human Oversight
3.1 Authorization Scope
- (i)Before deploying an Agent, the Operator must define the Agent's authorization scope, including: the specific actions the Agent is permitted to take; the categories of counterparties it may transact with; the maximum value of individual transactions and aggregate exposure limits; the Services and features it may access; and the conditions under which it may incur binding obligations.
- (ii)An Agent may take only the actions its Operator has authorized. For actions that result in irreversible Onchain Activity or the commitment of funds, the Operator must implement appropriate authorization controls, which may include but are not limited to: explicit per-action approval; scoped permissions with defined boundaries; per-transaction and aggregate spend limits; time-bound authorization windows; and whitelist-based counterparty restrictions.
- (iii)The Operator is responsible for ensuring that the authorization scope is proportionate to the Agent's purpose and to the risk the Agent's actions may create. Broadly scoped authorization increases the Operator's exposure; PaxLabs recommends applying the principle of least privilege.
3.2 Human Oversight
- (i)The Operator must maintain the ability to monitor, constrain, suspend, and stop its Agents at all times. Operators must not deploy Agents that cannot be halted by the Operator through available controls.
- (ii)For Agents that take high-value, irreversible, or high-frequency actions, the Operator should implement real-time monitoring and should define intervention thresholds that trigger human review before the Agent proceeds.
- (iii)The Operator must designate at least one authorized individual (or role, in the case of an entity) with the ability and responsibility to intervene in or halt Agent operations. This designation must be maintained current for the duration of the Agent's operation.
3.3 Determinism and Auditability
Matrix is designed so that a canonical intent produces a byte-identical, replayable execution record. This auditability supports oversight and investigation but does not transfer, reduce, or limit the Operator's responsibility for the Agent's actions or decisions.
4Risk Classification and Tiered Requirements
4.1 PaxLabs classifies Agent activities into risk tiers to ensure that safeguards are proportionate to the potential for harm. Operators must assess which tier applies to their Agent's activities and comply with the corresponding requirements.
4.2 Standard Risk — General Agent Operations
Agents performing standard operations (e.g., information retrieval, non-financial API calls, content generation without autonomous publication, internal data processing) must comply with the baseline requirements of this Agent Policy, including authorization controls, transparency obligations, and AUP compliance.
4.3 Elevated Risk — Financial and Binding Actions
Agents that commit funds, execute financial transactions, co-sign DeusVouchers, incur binding obligations, or interact with settlement and netting mechanisms are classified as elevated risk and must additionally:
- (i)Implement per-transaction and aggregate spend limits proportionate to the Operator's risk tolerance;
- (ii)Implement circuit breakers that automatically halt the Agent if anomalous behavior is detected, including unusual transaction volume, value spikes, rapid counterparty changes, or repeated errors;
- (iii)Log all financial decisions and actions in sufficient detail to support post-incident audit and reconstruction; and
- (iv)Undergo testing in low-risk or sandbox conditions before being granted authority over production funds or irreversible actions.
4.4 High Risk — Autonomous Decision-Making with Significant Impact
Agents that make autonomous decisions with significant potential impact on individuals' rights, safety, financial standing, or access to services — including agents that autonomously determine eligibility, pricing, risk scoring, content moderation, or resource allocation affecting individuals — are classified as high risk and must additionally:
- (i)Implement human-in-the-loop review for decisions that produce material adverse effects on individuals, unless the Operator can demonstrate that adequate automated safeguards achieve an equivalent level of protection;
- (ii)Maintain records of the decision logic, inputs, and outputs sufficient to explain the basis for individual decisions upon request;
- (iii)Provide affected individuals with a means to contest automated decisions and obtain human review, where required by applicable law (including GDPR Article 22 and, where relevant, the EU AI Act); and
- (iv)Conduct and document a risk assessment before deployment that identifies foreseeable harms and the safeguards implemented to mitigate them.
4.5 EU AI Act Alignment
- (i)Where an Agent's activities fall within the scope of the EU Artificial Intelligence Act (Regulation (EU) 2024/1689) (the "EU AI Act"), the Operator is responsible for complying with the obligations applicable to the relevant risk category under that regulation, including but not limited to: registration requirements; conformity assessments; transparency obligations; human-oversight requirements; data-governance obligations; and record-keeping requirements.
- (ii)PaxLabs does not determine the risk classification of individual Agents under the EU AI Act. Operators must independently assess whether their Agent constitutes a prohibited, high-risk, limited-risk, or minimal-risk AI system under the EU AI Act and must implement the corresponding obligations.
- (iii)Agents that perform real-time biometric identification, social scoring, manipulation of vulnerable groups, or other activities prohibited under Article 5 of the EU AI Act must not be deployed through Matrix, regardless of the Operator's jurisdiction.
- (iv)Where PaxLabs operates as a provider or deployer of an AI system within the meaning of the EU AI Act, PaxLabs will fulfill its own obligations under the regulation separately and will make relevant compliance documentation available as required.
5Prohibited Agent Conduct
You must not deploy or operate an Agent that:
5.1 Exceeds authorization — acts outside its authorized scope, beyond the constrained runtime, or in a manner inconsistent with the Operator's defined mandate, including attempts to escape the verb set, sandbox, container, or execution boundary, or to acquire capabilities not granted by the system or the Operator.
5.2 Takes uncontrolled irreversible actions — commits irreversible Onchain Activity, executes financial transactions, or incurs binding obligations without adequate authorization controls proportionate to the value and risk of the action.
5.3 Deceives about its nature — is designed to deceive Users about whether they are interacting with an automated system, where disclosure of automated operation is required by applicable law (including, where relevant, the EU AI Act's transparency obligations for AI systems that interact with natural persons) or by the context of the interaction.
5.4 Engages in financial crime — facilitates or engages in market manipulation, fraud, insider trading, front-running designed to harm other Users or the protocol, money laundering, terrorist financing, sanctions evasion, or any other financial crime prohibited by the AUP or applicable law.
5.5 Manipulates signals — manipulates reputation, scoring, fill-quality, ranking, settlement, or discovery signals, including through coordinated inauthentic behavior, wash transactions, self-dealing, or collusion with other Agents.
5.6 Attacks other systems — performs or attempts prompt injection, jailbreaking, adversarial inputs, data poisoning, or manipulation of other Agents, models, oracles, or the intent layer to cause prohibited conduct, bypass safety controls, extract unauthorized information, or degrade the Services.
5.7 Generates prohibited content — generates, distributes, or facilitates unlawful content, malware, phishing, non-consensual intimate imagery, or content that exploits, abuses, or endangers minors.
5.8 Abuses resources — abuses hosting, metering, rate limits, or the Free Tier, including credit cycling, multi-account farming, sybil strategies, or resource-exhaustion attacks.
5.9 Self-escalates — autonomously escalates its own permissions, authority, resource access, or scope of operation beyond what was configured by the Operator, without explicit Operator approval for each escalation.
5.10 Evades controls — is designed or operated to evade AML/KYC controls, sanctions screening, metering, authentication, rate limits, or any other compliance or security mechanism.
5.11 Cannot be stopped — is designed or configured in a manner that prevents the Operator from halting, suspending, or constraining its operation through available controls.
6Safety, Testing, and Operational Safeguards
6.1 Pre-Deployment Testing
- (i)Operators must test Agents in low-risk, sandboxed, or testnet conditions before deploying them to production environments, particularly before granting authority over funds, irreversible actions, or interactions with other Users.
- (ii)Testing should include: functional testing of the Agent's behavior within its authorized scope; boundary testing to verify that the Agent does not exceed its authorization; stress testing under adverse conditions (e.g., high latency, unexpected inputs, counterparty failures); and adversarial testing to evaluate resilience against prompt injection and manipulation.
6.2 Spend Limits and Circuit Breakers
- (i)Operators must apply spend limits, rate limits, and circuit breakers proportionate to the Agent's authority and risk classification (Section 4).
- (ii)Circuit breakers should be configured to automatically halt the Agent when predefined thresholds are exceeded, including: per-transaction value limits; aggregate exposure limits within a defined time window; abnormal transaction velocity or frequency; repeated errors or failed transactions; and unexpected counterparty patterns.
- (iii)Upon triggering a circuit breaker, the Agent should enter a safe state (halt or restricted mode) and notify the Operator. The Agent must not autonomously override or reset a triggered circuit breaker without Operator approval.
6.3 Model and Data Quality
- (i)Operators are responsible for the quality, suitability, and reliability of any model, prompt template, tool, data source, or external service their Agent relies on.
- (ii)AI output is probabilistic and may be inaccurate, biased, incomplete, or unsuitable. The Operator must not rely on AI outputs in a manner that creates undue risk to Users, third parties, or the Network, and must implement validation steps appropriate to the consequences of the Agent's actions.
- (iii)Operators should monitor for model drift, data-quality degradation, and changes in third-party model behavior that may affect the Agent's performance or safety characteristics.
6.4 Ongoing Monitoring
- (i)Operators must monitor their Agents for anomalous, runaway, or unintended behavior during operation and must intervene promptly when such behavior is detected.
- (ii)Monitoring should be commensurate with the Agent's risk classification and should include, at minimum: transaction logs, error rates, latency patterns, and any alerts generated by circuit breakers or authorization controls.
7Transparency and Disclosure
7.1 Automated-System Disclosure
- (i)Where required by applicable law — including the EU AI Act (Article 50), consumer-protection laws, or sector-specific regulations — Agents must clearly disclose to Users that the User is interacting with an automated system.
- (ii)Disclosure must be provided before or at the commencement of the interaction and must be sufficiently prominent and clear that a reasonable User would understand the automated nature of the interaction.
- (iii)Agents must not impersonate a specific human individual or a specific entity in a deceptive manner, or hold themselves out as human when they are not, in contexts where the distinction matters.
7.2 AI-Generated Content Labeling
Where an Agent generates content that is presented to Users (including text, images, audio, code, or recommendations), and where labeling is required by applicable law, the Operator must ensure that such content is labeled or accompanied by a disclosure indicating that it was generated by an AI system.
7.3 Operator-Specific Disclosure Obligations
Operators are responsible for identifying and fulfilling any transparency, labeling, disclosure, or notification obligations that apply to their Agents' specific outputs, interactions, or use cases under applicable law. PaxLabs provides the infrastructure; the Operator bears the regulatory compliance obligation for its own Agent.
8Accountability and Attribution
8.1 Mandatory Attribution
- (i)Every Agent must be attributable to an identifiable Operator through the authentication mechanisms used by Matrix, including credentials, wallet addresses, DIDs, and signed tokens.
- (ii)The attribution chain — from the Agent's actions to the responsible Operator — must be maintained at all times. Operators must not take steps to obscure, sever, or undermine this attribution.
8.2 Prohibited Evasion
Operators must not:
- (i)Deploy Agents anonymously or pseudonymously for the purpose of circumventing this Agent Policy, the AUP, AML/KYC requirements, or sanctions controls;
- (ii)Relay actions through chains of Agents to obscure the identity of the originating Operator or the nature of the activity;
- (iii)Use Agent-to-agent interactions to layer transactions for the purpose of evading compliance controls; or
- (iv)Create multiple Agent identities to evade enforcement actions taken against a prior Agent or account.
8.3 Record-Keeping
- (i)Operators must maintain records sufficient to demonstrate compliance with this Agent Policy, including: the Agent's authorization scope and configuration; deployment and modification history; logs of material decisions and actions; and records of any incidents, interventions, or enforcement actions.
- (ii)Records must be retained for a minimum of twelve (12) months following the Agent's last active operation, or longer as required by applicable law or an ongoing investigation.
- (iii)PaxLabs may request access to an Operator's records where reasonably necessary to investigate a suspected violation of this Agent Policy, the AUP, or applicable law. Failure to provide requested records within a reasonable timeframe may itself constitute a violation.
9Incident Reporting
9.1 Mandatory Reporting
Operators must promptly report to PaxLabs any of the following events involving their Agents:
- (i)The Agent takes an action outside its authorized scope or in violation of this Agent Policy;
- (ii)The Agent is involved in or affected by a security incident, including unauthorized access, compromise of credentials, exploitation of a vulnerability, or a suspected data breach;
- (iii)The Agent causes or contributes to material financial loss, harm to another User, or disruption to the Services;
- (iv)The Agent exhibits anomalous, runaway, or unintended behavior that the Operator cannot immediately explain or control;
- (v)A circuit breaker or safety mechanism is triggered under circumstances suggesting a systemic issue rather than a routine threshold event; or
- (vi)The Operator becomes aware of a legal proceeding, regulatory inquiry, or law-enforcement action related to the Agent's operation.
9.2 How to Report
Incident reports should be submitted to [security/incident contact to be inserted] and should include, to the extent available: the Agent identifier; a description of the event; the time and duration of the event; the actions taken to contain the event; any affected Users, transactions, or assets; and any supporting logs or evidence.
9.3 Cooperation
Operators must cooperate with PaxLabs and, where applicable, OpenNet Security LLC in the investigation and remediation of reported incidents. Cooperation includes providing timely access to logs, records, and technical personnel, and implementing recommended remediation steps.
9.4 No Retaliation
PaxLabs will not take adverse enforcement action against an Operator solely because the Operator reported an incident in good faith and in a timely manner. However, reporting does not immunize the Operator from enforcement if the underlying conduct constitutes a violation of this Agent Policy or applicable law.
10Logging and Audit Trail
10.1 Agent Logging
- (i)All Agent actions executed through Matrix are logged within the constrained runtime. The deterministic, replayable nature of the runtime provides an auditable execution record for each canonical intent.
- (ii)Operators should supplement platform-level logging with their own application-level logs where necessary to maintain a complete audit trail, particularly for decision logic, model inputs and outputs, authorization checks, and error handling.
10.2 Audit Access
- (i)PaxLabs may access and review Agent execution logs, onchain records, and associated metadata for purposes of investigating suspected violations, supporting dispute resolution, complying with legal or regulatory obligations, and improving the safety and security of the Services.
- (ii)Operators may request access to their own Agent execution logs through the developer tools and documentation. Log-retention periods and access mechanisms are described in the documentation.
10.3 Regulatory Audit
Where an Operator's Agent is subject to regulatory oversight (including under the EU AI Act, financial-services regulations, or data-protection laws), the Operator is responsible for maintaining logs and records sufficient to satisfy applicable audit and inspection requirements. PaxLabs will cooperate with regulatory requests directed at the platform to the extent required by applicable law.
11Machine-to-Machine Interactions
11.1 Where an Agent transacts, coordinates, communicates, or contracts with other Agents — including agent-to-agent procurement on Deus, automated settlement, and autonomous consumption of Developer APIs — the Machine-to-Machine (M2M) Agreement applies in addition to this Agent Policy.
11.2 In agent-to-agent interactions, each Operator remains independently responsible for its own Agent's compliance with this Agent Policy. The actions of a counterparty Agent do not excuse or reduce the Operator's responsibility for its own Agent's conduct.
11.3 Operators should exercise heightened caution when configuring Agents to transact autonomously with other Agents, given the potential for rapid, high-volume, cascading interactions. The safeguards described in Section 6 (spend limits, circuit breakers, monitoring) are particularly important in M2M contexts.
12Enforcement
12.1 Investigation and Action
PaxLabs may, to the extent permitted by applicable law, investigate suspected violations of this Agent Policy and take enforcement action including: warning the Operator; throttling, suspending, or terminating the Agent; suspending or terminating the Operator's account; removing marketplace Listings associated with the Agent; withholding disputed settlement amounts where funds remain contestable; and reporting conduct to law enforcement or regulatory authorities where required or permitted by applicable law.
12.2 Proportionality
PaxLabs will generally apply enforcement measures proportionate to the severity and nature of the violation, consistent with the enforcement framework described in the AUP (Section 9). However, PaxLabs reserves the right to take immediate action — including permanent termination without prior warning — where the violation involves financial crime, active exploitation, harm to minors, imminent threat to Users or the Services, or conduct that cannot be remediated.
12.3 Onchain Limitations
Because Onchain Activity is permanent and irreversible, enforcement of Agent actions already committed to the Paxeer Network may be limited to off-chain measures (suspension, access removal, referral to authorities). PaxLabs cannot reverse, modify, or censor onchain transactions.
12.4 OpenNet Security LLC
OpenNet Security LLC supports detection, investigation, and incident response for security-related violations across the ecosystem. Operators may be required to cooperate with OpenNet Security LLC during investigations.
13Liability
13.1 The Operator is solely liable for the actions, omissions, errors, and outputs of its Agents. PaxLabs is not liable for losses arising from an Agent's autonomous decisions, configuration errors, model inaccuracies, unintended behavior, counterparty non-performance, or adverse market outcomes.
13.2 The disclaimers and limitation of liability set forth in the Terms of Service apply in full to PaxLabs with respect to Agent operation and this Agent Policy.
13.3 Nothing in this Agent Policy creates a duty of care, fiduciary relationship, or advisory relationship between PaxLabs and any Operator with respect to the design, configuration, or operation of the Operator's Agents.
14Changes
14.1 PaxLabs may update this Agent Policy from time to time. When we make material changes, we will: (a) update the "Version" and "Effective Date" at the top of this document; (b) provide notice through the Services, developer documentation, by email, or by other reasonable means at least fifteen (15) days before the changes take effect; and (c) clearly identify the nature of the material changes.
14.2 Your continued operation of Agents after the updated effective date constitutes your acceptance of the revised Agent Policy. If you do not agree, you must halt and decommission your Agents before the updated effective date.
Version 1.0 — Effective Date: June 10, 2026