Skip to main content
Content Access Management is Corgea’s project-level access control system. It allows you to control who in your organization can view and interact with specific projects and their security data. By default, all users in your company can access all company projects. With Content Access Management enabled, you can restrict access so that users only see projects they’ve been explicitly granted access to. This feature is essential for organizations that need to:
  • Separate access between different teams or departments
  • Restrict sensitive projects to specific individuals
  • Comply with security policies that require access segregation
  • Manage contractor or external consultant access

​
How Does It Work?

Content Access Management operates at two levels:

​
Company-Level Setting

Your company has a Project Access Control toggle that determines the overall access model:
  • Disabled (Default): Open access model - all users in your company can access all company projects
  • Enabled: Restricted access model - users can only access projects they’ve been explicitly granted access to

​
Project-Level Access

When Project Access Control is enabled, users gain access to a project through one of three ways:
  • Team Members
  • Project Members
  • Project Owners
Users who belong to a team assigned to the project automatically receive member-level access. This provides the same permissions as direct members but is managed at the team level rather than per-project.Learn more about teams in our Teams Guide.

​
Special Cases

API Access: Access control applies to both the web interface and API calls. Users can only access project data through the API if they have proper permissions.

​
How to Implement Content Access Management

1

Enable Project Access Control

Required Permission: Company administrator access
  1. Navigate to your Company Settings
  2. Locate the Project Access Control setting
  3. Enable the toggle for “Project Access Control”
  4. Save your changes
Once enabled, users will immediately lose access to projects where they haven’t been explicitly granted access. Plan your rollout accordingly.
2

Assign Access to Projects

Required Permission: Change Project permission or project owner role
After enabling Project Access Control, you need to grant users access to projects:
  1. Navigate to the Content Access page
  2. You’ll see a list of all your company’s projects
  3. For each project, you can:
    • View current members and teams
    • Add new users as owners or members
    • Add teams to the project
    • Remove existing access
  • Adding Individual Users
  • Adding Teams
  1. Click on the project you want to manage
  2. Select Add Member or Add Owner
  3. Choose the user from your company’s user list
  4. Select their role:
    • Owner: Full project control
    • Member: View and interact with security data
  5. Confirm the addition
3

Verify Access

After assigning access:
  1. Review the Content Access page to ensure assignments are correct
  2. Test with a user account to verify they can access appropriate projects
  3. Check that users without access cannot see restricted projects
4

Ongoing Management

As your organization evolves:
  • New Projects: Assign owners and members when creating new projects
  • New Users: Add them to relevant projects or teams
  • Role Changes: Update access when people change roles
  • Departures: Remove access when people leave teams or the company

​
Best Practices

Before turning on Project Access Control:
  • Document which users should have access to which projects
  • Consider creating teams first to simplify assignment
  • Communicate the change to your organization
  • Consider starting with a pilot group of projects
For projects with multiple users, use teams instead of individual assignments:
  • ✅ Add “Backend Team” to 10 projects (10 operations)
  • ❌ Add 15 individual users to 10 projects (150 operations)
Teams also make ongoing management much easier.
Every project should have at least one owner who can:
  • Manage project settings
  • Add/remove other users
  • Handle project-specific configuration
Without an owner, projects become difficult to manage.
Use ownership strategically:
  • Owners: Project leads, managers, senior engineers responsible for the project
  • Members: Contributors, reviewers, stakeholders who need visibility
Don’t make everyone an owner—it reduces accountability and increases security risk.
Schedule periodic reviews of project access:
  • Quarterly or bi-annually, review who has access to each project
  • Remove access for users who no longer need it
  • Update access for users whose roles have changed
  • Export access data for compliance purposes
The Content Access page includes search functionality:
  • Quickly find specific projects
  • Search for users to see which projects they can access
  • Filter to identify projects with unusual access patterns
Required Permission: Content access view permission
Export your access configuration for:
  • Compliance audits
  • Security reviews
  • Documentation purposes
  • Backup before making bulk changes
Use the Export button on the Content Access page to download a CSV of all project access assignments.
Match your access control to how your organization actually works:
  • If teams are siloed (separate frontend/backend/mobile), use strict access control
  • If teams are fluid and collaborative, you might prefer open access
  • Use a hybrid approach: open access for most projects, restricted access for sensitive ones (though this requires keeping some projects in a separate company space)
When modifying access:
  • Inform affected users before removing their access
  • Explain why access is being granted or revoked
  • Document your access policies so users understand the rules
When in doubt:
  • Grant member access instead of owner access
  • Users can always request elevated permissions if needed
  • It’s easier to grant additional access than to revoke it

​
Frequently Asked Questions

They immediately lose access to all projects where they haven’t been explicitly assigned as owners, members, or through a team. Plan accordingly and assign access before or immediately after enabling the feature.
No. Project Access Control is a company-wide setting. It’s either enabled for all projects or disabled for all projects within your company.
Owners can configure project settings, manage access, and delete projects. Members can view and interact with security data but cannot modify project configuration or manage access.
They have access through both paths. Removing them from the team doesn’t affect their direct member access, and vice versa.
No. When Project Access Control is enabled, users can only see projects they have access to. Projects they cannot access are completely hidden.
Yes. API calls and integrations respect the same access control rules as the web interface.
Yes, you can toggle Project Access Control on and off. However, each time you disable and re-enable it, you’ll need to verify access assignments are still appropriate.
Project owners can manage access for their specific projects. Company administrators can manage access for all projects. Regular members cannot manage access.
No. Access control only affects who can view projects and their data. It doesn’t change how Corgea scans repositories or generates fixes.
Related Documentation:
  • Teams Guide - Learn how to create and manage teams for efficient access control
  • User Management - Managing users in your organization
Need Help? Contact Corgea support for assistance with setting up or managing Content Access Management for your organization.