> For the complete documentation index, see [llms.txt](https://rwapact.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rwapact.gitbook.io/whitepaper/security-and-risk-model/policy-enforcement.md). # Policy Enforcement Explains how RWAPACT enforces configurable trading policies covering asset permissions, trade limits, slippage, concentration, oracle freshness, liquidity, and risk thresholds. ## Policy Enforcement Session authorization and policy enforcement answer different questions. A session asks: > Is this agent currently authorized to act? A policy asks: > Does this specific trade comply with the rules configured for that agent, owner, or asset? KSO validates delegated authority, session status, scope, and budget. KPV, the Policy Vault, evaluates the requested trade against the active trading policy. A valid session does not bypass policy. KPV enforces configurable rules before a trade reaches the execution layer. It evaluates the trade intent with current risk and market context. It is not a recommendation system. It does not predict whether a trade will be profitable. ### Policy parameters The active policy defines the constraints that apply to a trade. | Policy parameter | What it controls | Example failure | | ------------------------ | -------------------------------------------------------- | ---------------------------------------------------------------- | | Allowed assets | Assets permitted by the policy | The requested tokenized stock is not permitted. | | Maximum trade size | Maximum amount for one trade | The requested amount exceeds `maxTradeSize`. | | Daily limit | Total permitted trading during a day | The trade would exceed the remaining daily limit. | | Maximum concentration | Maximum portfolio share held in one asset | The purchase would take the position above the configured limit. | | Maximum slippage | Highest acceptable estimated execution slippage | Estimated slippage exceeds the policy maximum. | | Fresh oracle requirement | Whether current oracle data is mandatory | The oracle timestamp is outside the permitted freshness window. | | Minimum liquidity | Lowest acceptable available liquidity | Pool liquidity is below the configured minimum. | | Off-hours policy | Whether trading outside relevant market hours is allowed | The market is closed and off-hours trading is disabled. | | Risk score threshold | Highest KRO score allowed by the policy | KRO returns `45`, above the policy threshold. | Each parameter constrains a different part of autonomous RWA trading. Asset permissions prevent activity in unapproved instruments. Trade and daily limits constrain exposure. Concentration limits prevent a single holding from dominating the portfolio. Slippage and liquidity checks assess whether the requested size can trade under acceptable conditions. Oracle freshness protects decisions from outdated price context. The off-hours policy accounts for market-calendar conditions. The risk score threshold binds KRO's current assessment to the owner's configured tolerance. If a trade violates a parameter, KPV rejects it. The trade does not reach execution. The rejection reason becomes part of the decision context for KAR. ### Intent and current context KPV evaluates a proposed action, not a general trading strategy. Its inputs include the asset and amount from the trade intent, the active policy, and relevant context from the Pact. This keeps policy enforcement deterministic and rule-based. KPV tests configured constraints. It does not substitute discretionary judgment for those constraints. KRO evaluates current RWA risk conditions. KPV determines whether those conditions and the requested trade satisfy the active policy. For example, KRO may calculate a risk score of `45`. KPV can still reject the trade if the policy allows only lower scores. ### Policy Versioning RWAPACT policies are versioned. The active policy version is part of the decision context. KAR includes that version in the attestation. This preserves the policy configuration governing a specific decision. A later audit can determine which policy version applied when RWAPACT allowed or rejected the trade. Versioning does not change an earlier decision. It records the policy state associated with that decision. ### Example: session valid, policy rejected An agent requests a purchase of a tokenized stock. Its session is active. The asset is within session scope. The oracle is fresh. Liquidity is sufficient. The requested amount exceeds KPV's configured maximum trade size. KPV rejects the trade. * The trade does not reach execution. * The rejection reason becomes part of the decision context. * KAR can record the rejection. The example shows the boundary between delegated authority and policy compliance. KSO confirms that the agent may act. KPV confirms whether this trade is permitted. ### Policy as an Execution Boundary KPV turns configured trading rules into an enforceable boundary between agent intent and execution. It ensures that autonomous RWA trading remains within the limits selected by the owner or protocol. KPV does not replace KRO, KSO, KGR, or KAR. KRO supplies risk context. KSO validates session authority. KGR evaluates gas conditions. KAR preserves the resulting decision record. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rwapact.gitbook.io/whitepaper/security-and-risk-model/policy-enforcement.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.