> ## Documentation Index > Fetch the complete documentation index at: https://docs.getpara.com/llms.txt > Use this file to discover all available pages before exploring further. # Create policies in Developer Portal > Configure a policy with the Developer Portal forms, then activate it on a Development key Para Permissions lets you control which transactions wallets can sign. You configure policies in the [Developer Portal](https://developer.getpara.com), test them against a Development API key, and work with Para to publish the production configuration. App-owned wallets can sign by default unless a Guardrail blocks the transaction. User-owned wallets require review unless the user has granted a matching Request. Permissions supports EVM, Solana, Cosmos, Stellar, and Sui signing routes. The Developer Portal forms cover a subset of policy shapes; use [JSON authoring](/v3/cli/permissions) or work with Para for other supported configurations. Select the wallet type and signing route explicitly, and check the [policy reference](/v3/references/permissions/policy-json) for the facts supported by each request. ## Choose a policy type Permissions separates two different wallet experiences: | Policy type | Use it for | What it does | | -------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Guardrails** | App-owned wallets used through the REST API | Sets limits for selected transaction types. A selected transaction outside those limits is denied; other app-owned signing stays allowed. | | **Requests** | User-owned wallets used through a Para SDK | Lets the user grant standing access for matching transactions. Future matching transactions can sign without another prompt when no other applicable policy denies them or requires approval; other transactions require manual review. | Requests always require user consent. Guardrails do not show a consent request because the application owns the wallet. Developer Portal Permissions page with Guardrails and Requests tabs ## Configure a Development policy Start with a Development API key. Policies created for one API key do not affect another key. Select your project and **Development** API key in the Developer Portal, then open **Permissions** from the sidebar. Choose **Guardrails** or **Requests** based on the wallet ownership model above. Select **Add**. For a Request, enter the plain-language text users will see when deciding whether to grant access. Select one or more networks and, if needed, an optional start and end time for the policy. Create Request Policy form with consent language, network selector, and optional policy window Add the actions the app needs and narrow each action with an available condition. For example, allow native transfers on Ethereum up to a fixed amount, or limit a contract call to a particular function and argument. Request Logic step showing a transaction action, network, conditions, and required consent Select **Review** to inspect the server-normalized policy and any warning about broad access. Select **Save Draft** only when the summary matches your intent. A draft is inert and does not change signing behavior. Review step summarizing the policy and warning that no conditions were configured Activate the draft when you are ready to use it on the Development key. The first active policy automatically enables Permissions for that key. A policy affects signing only while it is active and within its time window. Test at least one transaction that should match and one that should not before requesting production review. Saving and activating are separate actions. **Save Draft** does not enforce the policy. After permissions have been enabled, deactivating every policy does not remove the ownership-based signing defaults. ## Actions and conditions The current Portal flow supports these transaction actions: * Transfer ETH * Transfer tokens * Call a contract * Execute a Safe transaction * Deploy a contract Depending on the action, you can set per-transaction or cumulative spending limits for native and ERC-20 transfers, restrict recipients, or require a specific contract, function, or argument. An optional policy window controls when the policy applies. The available controls are described in the [Permissions Reference](/v3/references/permissions/policy-json). The Portal covers common policy shapes. For several conditions on one action, nested logic, other supported wallet types, or multiple rules that work together, use [JSON authoring with the CLI](/v3/cli/permissions) or contact Para for assistance. ## Selectors and versions The policy type and complete network selection identify the policy you are editing. Network order does not matter, so **Ethereum + Base** is the same selector as **Base + Ethereum**. **Base only** is a different selector and creates an independent policy. Editing an existing selector creates the next version of that policy. Changes to an active policy replace the active version when saved, while changes to a draft remain in draft. Resolve the current draft by activating or discarding it before creating another draft. Editing an active policy and selecting **Save changes** replaces the active version immediately. Test active-policy changes on the Development key before requesting a Production update. ## Production Development and Production API keys are independent. Creating a Production key does not copy the Development policy, activate Permissions, or change the Production key's existing signing behavior. After you have validated the active Development policy: 1. Create the Production API key. 2. Open the Production key and select **Request production review**. This action appears when Development has an active policy and the Production key is still awaiting permissions setup. 3. Para reviews the active Development policy and independently publishes the approved policy for the Production key. 4. Verify the published Production policy in the Portal before sending production traffic. The Production Permissions page is read-only. It can appear empty until Para publishes the approved policy. ## Integration guides Handle consent and transaction review for user-owned wallets on the web. Open transaction review URLs from a native application. Restrict signing for app-owned wallets used through the REST API. Explore the full policy JSON language, selectors, conditions, and approval requirements.