# 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

***
## 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

***
## 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

***
## 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)