Control what each user sees. Control what each user can do. At any layer.

Why it matters

In multi-stakeholder review at enterprise scale, permission failures show up in two recognizable ways.

The first is content leakage. Someone sees content they should not have access to. Sensitive sections of a regulatory submission visible to marketing reviewers. PHI visible to people without clearance. Pre-launch material visible to teams that should not know about it yet. The blast radius of these leaks ranges from awkward to compliance-violating to legally actionable.

The second is action overreach. Someone with access to content has the ability to do something they should not. A junior reviewer overriding a senior approval. A brand reviewer making a regulatory decision. An external agency contact invoking an AI Agent that should be internal-only. Even when no malicious intent is involved, action overreach corrupts the audit trail and erodes trust in the process.

Aproove's two-dimensional permission model addresses both failure modes. Content permissions control the leakage side. Action permissions control the overreach side. Both work at fine granularity. Both are enforced at the platform layer, not the application layer, which means they hold even when users approach the system through APIs, integrations, or unconventional access paths. This matters for teams evaluating document version control software for agencies.

Two dimensions of control

Content permissions answer the question: what can this user see?

• An entire project (does the user have project-level access at all?)
• Specific files within a project (some files visible, others not, even within the same project)
• Specific sections of a file (legal sections visible to legal, brand sections visible to brand)
• Specific pages of a section (pages 12 through 18 visible, the rest not)
• Specific components of a page (a specific image, paragraph, or region)

Action permissions answer the question: what can this user do?

• Which markup tools they can use (text extraction, region marking, freehand annotation, and others)
• Which Notes they can create, edit, or delete
• Which decision buttons they see at any given workflow step (Approve, Reject, Approve with Comments, Send to SME, Hold for Compliance, and so on)
• Which AI Agents they can invoke (a brand reviewer might see brand Agents but not legal Agents)
• Which export and download permissions they have (some users can export the proof PDF, others cannot)
• Which administrative functions they can perform (workflow editing, user management, schema configuration)

The dimensions multiply: a user with broad content permissions might have narrow action permissions, or vice versa. The combination is what defines that user's experience.

What you can gate on the actions side

Specific examples of what action permissions control:

• AI Agent access. Which Prompt Template Sets the user can invoke. A regulatory reviewer might have access to regulatory Agents only. A brand reviewer might have access to brand Agents only. AI access is independent of file access.
• Note creation, editing, and deletion. Some roles can create Notes and edit their own. Other roles can edit any Note. Other roles can delete Notes. Each is configurable.
• Decision buttons available. A workflow step might define decision buttons including Approve, Reject, Approve with Conditions, and Escalate. Different roles can see different subsets. A junior reviewer might only see Approve and Reject. A senior reviewer sees the full set including Escalate.
• Markup tools available. The Review Interface offers multiple markup tools (text extraction, region selection, freehand annotation, color picker). Roles can be granted access to specific tools rather than all of them.
• Export and download. Some roles can download original files; others can only view them in the streaming viewer. Some can export PDFs of proofs and comments; others cannot.
• Workflow and admin functions. Workflow editing, user management, schema configuration, and other administrative capabilities are gated to admin roles, with optional sub-tiers (a workflow admin who can edit workflows but not manage users, for example).

What you can gate on the content side

Specific examples of what content permissions control:

• Project visibility. Whether the user can see a project at all. Users who do not have project-level access do not see the project in their dashboard.
• File-level visibility. Within a project, which files the user can open. A project may contain multiple proofs; not every reviewer needs to see all of them.
• Section-level visibility. Within a multi-section file, which sections the user can see. Different sections of a complex regulatory document might route to different specialist teams, with each seeing only their section.
• Page-level visibility. Within a file, which pages the user can see. Pages tagged as confidential, regulated, or sensitive can be gated to roles with appropriate clearance.
• Component-level visibility. Within a page, which components the user can see. A specific image flagged as PHI, a paragraph containing financial confidentials, a region carrying restricted information. The component is what gets gated, not the whole page.

How permissions map to roles, teams, and users

Permissions are assigned at multiple levels of the user model, and resolve in the way that matches your governance.

• Role-based. The most common pattern. Permissions are defined per role, and users inherit them by being assigned to the role. A "Legal Reviewer" role carries a defined set of content access and action capabilities. Adding a person to the role gives them everything the role has.
• Team-based. Permissions can be scoped to teams, where a team's permissions apply to its members. Useful for cross-functional groups that need a shared permission profile.
• User-specific. Where role and team assignments are not enough, permissions can be granted directly to individual users. Rare in practice, but available when the work requires it.
• Metadata-driven. Permissions can resolve based on project or component metadata. A user might have legal review access to documents tagged as US jurisdiction but not EU jurisdiction. The permission is conditional on the metadata of the content being reviewed.

The combination resolves cleanly: the user gets the union of permissions they qualify for through role, team, and direct assignment, scoped by any metadata conditions that apply.

Common patterns

Security clearance gating. A document contains sections at multiple sensitivity levels. Permissions are configured so that users see only the sections their clearance level permits. The same document serves multiple reviewer pools, each seeing what they should.

Role-based action restriction. A workflow step has multiple decision buttons. Junior reviewers see only Approve and Reject. Senior reviewers see Approve, Reject, Approve with Conditions, and Escalate. Conflict Managers see an additional Override option. Same step, different action vocabularies.

Component-level routing with permission enforcement. AI Agents flag risk on specific components. Those components route to specialists based on the risk type. Permissions ensure the specialist sees their flagged components and not the rest of the file. Other reviewers continue with the unflagged content.

External user gating. Agency or external partner users have a constrained permission profile: limited content access, limited action capability, no AI Agent invocation, no admin functions. They participate in review but cannot exceed the boundary defined for them.

Benefits

• Two dimensions of control, one model. Content visibility and action capability are configured together, with consistent role, team, and user mapping.
• Granularity to the component. Permissions go deeper than file-level. Specific pages, sections, or components can be gated independently.
• AI access is permission-controlled. Who can invoke which Agent is governed at the role level, independent of file access.
• Decision authority is permission-controlled. Which decision buttons a user sees is per-role, so junior and senior reviewers operate within their defined authority.
• Sensitive content stays gated. PHI, PII, regulated material, or pre-launch content can be configured to stream only to cleared roles.
• External users have bounded experience. Agency partners, client reviewers, and other external participants operate within constrained permission profiles.‍
• Audit trail captures permission events. Permission grants, changes, and access events are part of the project audit trail, supporting governance and compliance review.

Who it's for

• Compliance, legal, and regulatory teams in industries where content access controls are mandated by regulation.
• Brand governance teams managing review across many stakeholder groups with varying scopes of authority.
• IT and security teams evaluating platforms against access control, data residency, and least-privilege requirements.
• Operations leaders running review programs with multiple internal teams, external partners, and varying authority levels.‍
• Customers in regulated industries (pharma, healthcare, financial services, government) where layered access control is a procurement requirement.

Under the hood

Layered Access Control is implemented through Aproove's two-tier permission model: content permissions and action permissions. Content permissions are stored at the project, file, section, page, and component levels, with resolution computed per user based on role assignments, team memberships, direct user grants, and metadata-driven conditions. Action permissions are defined per role and govern available decision buttons, markup tools, AI Agent invocations, Note operations, export and download capabilities, and administrative functions. Permission resolution computes the union of permissions a user qualifies for through any assignment path, scoped by metadata conditions. Permissions are enforced at the platform layer rather than the application layer, meaning they hold for API access, integration access, and any other access path. The streaming layer enforces content permissions per tile request, so content the user is not permitted to see is never streamed to their device. Permission grants, changes, and access events are captured in the project audit trail. The Kroger Promotional Execution Centre of Excellence Transformation white paper (Aproove, October 2021) cites the platform handling "over One Hundred Million sets of permissions across hundreds of thousands of tasks" as evidence of the model's scalability.