# Access Rules & Permissions (Security Policies) Security Policies Security policies control what users can see, update, or interact with across the Kinetic Platform. Whether you're building a workflow, designing a form, or setting up team access, policies help you enforce the right rules at the right level. Policies are powered by security defini... # Security Policies Security policies control what users can see, update, or interact with across the Kinetic Platform. Whether you're building a workflow, designing a form, or setting up team access, policies help you enforce the right rules at the right level. Policies are powered by **security definitions**, which are flexible JavaScript rules that evaluate user identity, team membership, attributes, and more. *** ## Security Policy Hierarchy Security policies follow a clear **inheritance hierarchy**, where the platform checks from the most specific to the most general level. > **In ascending order of scope and fallback:** > > 1. **Form** > 2. **Kapp** > 3. **Space** If a policy is not defined at the form level, the platform checks the kapp. If none is defined at the kapp level, it uses the space-wide default. This means: - **Define policies at the lowest level possible** to ensure the most accurate control. - **Only use space-level policies as fallbacks or broad rules** for all users. *** ## Form-Level Policies (Most Specific) These are policies applied directly to an individual form. These are the most targeted and recommended for use when possible. - **Form Display** – Who can see or access the form - **Form Modification** – Who can update the form definition - **Submission Display** – Who can view individual submissions - **Submission Modification** – Who can update submissions - **Allow Anonymous Submissions** – (Toggle) Found under: `Form > Settings > Security`
See An Example ![](https://files.readme.io/8a05fb8ef93f6205fd615387bffa8f04bde6b807544441e98d73d2c029969dfe-image.png)
*** ## Kapp-Level Policies Used to define **default** policies across all forms within a kapp. If no form-level policy is set, these rules apply. - Default Form Display / Modification - Default Submission Display / Modification - Kapp Display (who sees the kapp) - Kapp Modification (who can change kapp configuration) Found under: `Kapp > Settings > Security`
See An Example ![](https://files.readme.io/0607e30d823f3b62eacaa44fad4baa8b83f85b691ecf7d4ecc11753562a2ce62-image.png)
*** ## Space-Level Policies (Global Fallback) Space-wide policies act as a global safety net. These typically manage administrative permissions and default behaviors when no other level provides a rule. - Who can create, modify, or view: - Users and Teams - File Resources - Spaces and Kapps - Admin Console access - API and system-level access Found under: `Space > Settings > Security`
See An Example ![](https://files.readme.io/48b5589b6398b88f3fecf086471a7f521f54fcfbb66604e33e457df3d124efc6-image.png)

*** ## Applying a Security Policy To apply a policy: 1. Navigate to the **Form**, **Kapp**, or **Space** you want to secure 2. Go to the **Security** tab 3. Select an existing **Security Definition** or create a new one 4. Assign the definition to a specific policy type (e.g., Submission Display) Learn more about creating definitions in the [Security Definitions](./security-definitions.md) page. *** ## Best Practices - **Start small**: Use form-level policies first before defining broad kapp/space rules - **Reuse definitions**: Keep logic consistent and avoid duplication - **Test with a non-admin account**: Always confirm what different users can see - **Be cautious with Submission Display**: - If a user tries to retrieve 25+ submissions they can’t access, the query fails > ⚠️ Heads up! Space Admins bypass security policies. > > When testing access rules, keep in mind that **Space Admins automatically have full access**, regardless of form, kapp, or submission-level policies. > > To properly validate your security configurations, always test with a non-admin user account that reflects your intended access scenario. *** ## Real-World Examples - "Only users in the `HR` team can submit onboarding forms" - "Users can only view their own submissions" - "Form should only be visible during business hours" - "Only assigned reviewers can update a request after submission" *** ## Related Topics - [Security Definitions](./security-definitions.md) - [Workflow Security](./workflow-security.md) - [Submission Access Considerations](./submission-access.md) - [Authentication & Login Methods](./authentication.md)