cloudflareAug 14, 2026

How Cloudflare detects MCP traffic and helps secure it (opens in new tab)

AI agents change the risk model for resource permissions because they make nondeterministic decisions and can repeat actions at machine speed. A mistaken judgment that a human might quickly catch can become thousands of harmful operations before anyone notices. Cloudflare’s new Cloudflare One capabilities aim to detect MCP traffic, identify its users and servers, and enforce approved routes through MCP Server Portals. ## Why AI Agents Require New Controls - Traditional permissions assumed users would apply judgment and act at a limited human pace. - AI agents can invoke tools repeatedly and indefinitely. - A single incorrect decision can rapidly propagate across databases, SaaS systems, or infrastructure. - MCP makes it easy to connect clients such as Claude Code, Codex, Cursor, OpenCode, and VS Code to approved or unapproved tools. - Direct MCP traffic can resemble ordinary HTTPS because MCP does not require a standard hostname or `/mcp` path. ## Anatomy of an MCP Tool Call An MCP request appears differently at three points: - **Client:** The agent decides to invoke a tool and supplies arguments. - **Network:** The request is transmitted as an HTTP transaction containing JSON-RPC. - **Server:** The server authenticates, validates, and dispatches the request to a tool handler. Useful protocol signals include: - Destination hostname and path - Authorization credentials - `MCP-Protocol-Version` - `Mcp-Method` - `Mcp-Name` - JSON-RPC request `id` - Tool arguments in `params` The tool name indicates the intended operation, while the arguments may contain sensitive data such as source code, customer information, search queries, or infrastructure-changing instructions. Responses can also contain sensitive results, making both request prevention and response inspection valuable. ## Controls Inside the MCP Client Client hooks can intervene after the model selects a tool but before the request is serialized. - Enforce server allowlists - Require confirmation for sensitive operations - Remove sensitive data from arguments - Support local `stdio` MCP servers that never generate network traffic The main limitation is operational: organizations must implement controls across every client employees use. Client telemetry also cannot provide a complete inventory unless the organization manages all relevant clients and devices. ## Controls at the Network Boundary A secure web gateway with TLS decryption can inspect remote MCP traffic independently of the client. - Associate requests with users and devices - Inspect destinations and MCP protocol headers - Detect direct connections outside approved MCP Portals - Block unauthorized traffic before it reaches the server - Use data loss prevention scanning to inspect JSON-RPC methods and arguments Network controls provide the broadest visibility into remote MCP usage, but they cannot see local `stdio` calls or traffic that bypasses managed network paths. ## Controls at the MCP Server The server has the deepest execution context because it knows the authenticated caller, parsed message, resolved tool, and validated arguments. Server-side middleware can: - Authorize users for specific tools - Apply rate limits - Inspect arguments - Log outcomes - Block requests before tool execution Cloudflare’s WriteGuard applies this approach to internal MCP servers by assigning tools risk tiers and enabled or disabled states. It can allow reads, attach attribution and audit events to approved writes, or block critical actions before their handlers run. Because enforcement occurs on the server, users cannot bypass it by changing clients or disabling local hooks. ## Layered MCP Security Each control point has a different strength: - **Client controls:** Earliest intervention and support for local MCP, but limited coverage. - **Network controls:** Broadest visibility into remote traffic and unmanaged MCP connections. - **Server controls:** Richest context and final prevention point before execution. A layered strategy can protect sensitive data before it leaves a device, identify shadow MCP usage, require trusted Portal-based access, and prevent unauthorized tools from executing.

access-controlai-agentmodel-context-protocoldata-loss-prevention+4

cloudflareAug 5, 2026

The Agent Access Model (opens in new tab)

BeyondCorp established that access should depend on identity and device health rather than network location. The post argues that this human-centered model is inadequate for ephemeral, fast-moving, and highly composable software agents. It proposes the Agent Access Model (AAM), which limits an agent’s capability to a specific task, evaluates every action against evolving task state, and enforces controls in the execution harness and network rather than relying on prompts. ## The Shift from Humans to Agents - Traditional Zero Trust assumes a legible human principal: - A person uses a small number of devices. - Activity occurs at human speed. - Access decisions can be evaluated over time using SSO, device posture, and risk scoring. - Agents have a different operating model: - A task-scoped run is ephemeral and ends when its work is complete. - A long-lived service may execute many independent tasks. - Agents can access databases, source control, logs, ticketing systems, documents, and other systems in rapid succession. - Least privilege must therefore become real-time and task-specific rather than a periodic policy review. ## Why Human-Oriented Controls Fail - **Durable credentials outlive ephemeral work** - Service-account keys and broad scopes may remain available after a task ends. - Credentials can persist in memory, logs, or environment variables. - Agent credentials should expire with the task and typically live only for minutes. - **Machine-speed activity bypasses slow detection** - An agent can read sensitive data and transmit it externally before human-tuned anomaly or DLP systems react. - Preventive controls must operate inline at tool-call and network boundaries. - **Prompts cannot enforce security boundaries** - Instructions such as “do not access production” can be overridden by malicious content or unsafe model behavior. - Intent may inform risk decisions, but enforcement must occur in the harness and network layer. - **Authority can disappear across delegation chains** - Agents may call tools that invoke other agents and APIs. - Existing identity and delegation mechanisms struggle to preserve the original human, task, and permissions across multiple hops. ## The Agent Access Model - AAM’s central rule is: **do not trust the task execution graph; authorize every action.** - Each action is evaluated against: - The agent’s identity. - The human or system principal it acts for. - The authorized task. - Resources already accessed by the task execution graph. - Accumulated task state can only reduce remaining capabilities; authorization for one action does not automatically authorize later actions. - AAM complements systems such as Beyond Zero by shrinking the capability set that authorization engines must evaluate and recording the agent, principal, and task behind each decision. ## AAM’s Five Principles - **Short-lived, bound credentials** - Credentials are minted for a specific task, expire with it, and are sender-constrained. - A stolen token cannot be replayed without the harness-held proof key. - **Enforcement outside the prompt** - The harness mediates tool calls. - The network mediates packets. - Prompts communicate intent but are not security boundaries. - **Exceptional human oversight** - Human approval is reserved for genuinely consequential decisions. - Requiring approval for every step causes fatigue and habitual clicking. - **Evidence-based grant review** - Captured activity reveals whether task templates are too broad or too narrow. - Approved policy changes apply only to future tasks and never expand the permissions of an active task. - **One-way capability reduction** - A declared protected event triggers the Trust Ratchet. - Capabilities are removed across the task execution graph according to policy. - Removed authority can return only through a newly authorized task. ## Reference Architecture - AAM describes a reference architecture with: - Four active controls governing the task. - An Agent Activity Log that records evidence. - A Grant Review Loop that uses that evidence to improve future grants. - The architecture is intended to define security guarantees and component responsibilities rather than prescribe a specific wire-level implementation. - At dispatch, the Agent Identity Broker issues a verifiable, short-lived credential scoped to the task. - The credential identifies: - The agent. - The principal on whose behalf it acts. - The authorized task. - It must expire no later than the task itself and be sender-constrained to prevent token-only replay. A practical implementation should treat each agent run as a bounded, independently authorized execution graph. Enforce permissions inline at the harness and network layers, use short-lived task-bound credentials, continuously reduce capability when risk changes, and use audit evidence to refine future grants without widening permissions during an active task.

access-controlzero-trustaudit-loggingleast-privilege+2

cloudflareAug 5, 2026

Cloudflare OS: an open platform for agents, apps, and work (opens in new tab)

Cloudflare OS is an open-source platform that gives every employee an agent workspace grounded in their organization’s terminology, procedures, systems, and best practices. It combines conversational agents, code execution, connected apps, workflows, and governed access to internal data. Cloudflare’s experience showed that security and resource-level authorization must be built into the platform rather than left to individual users or app developers. ## Why Organizations Need More Than Coding Agents - Code provides a clear feedback loop: it either works or fails. - Other organizational work—documents, research, processes, relationships, and physical-world outcomes—is harder for agents to support. - Agents need both: - Context about how the company operates. - Access to the systems employees use. - Cloudflare OS was created to apply agent leverage across the entire organization, not only engineering. ## Lessons from the First Version - Cloudflare’s initial system gave employees private agent workspaces. - Early limitations included: - Static apps that were not connected to live internal systems. - Repeatedly rerunning agent skills for mostly deterministic tasks, consuming additional model tokens. - Collaboration risks when users shared workspaces, apps, and outputs. - MCP servers could define which tools an agent could call, but not which underlying resources the agent had seen. - The platform therefore needed security that tracked data access and possible downstream exposure. - The new version makes security, governance, customization, and organizational context core platform features. ## Cloudflare OS Platform Components Cloudflare OS combines: - **Agent workspaces:** Browser-based environments with sessions, persistent state, files, resource access, and isolated code runtimes. - **Security and governance:** Controlled access to internal services and data. - **Personal and collaborative apps:** Modifiable applications that users can build, share, and continue evolving. - Conversations can become documents, applications, or workflows that continue operating after the initial interaction. ## Agent Workspaces for Everyone - Employees can use workspaces through a browser without being developers or using a terminal. - Company-curated skills and context prevent users from repeatedly explaining terminology, processes, and best practices to an AI model. - Shared skills allow improvements discovered by one person to benefit the wider organization. ### Research and Analysis - Agents can research using approved company context and resources. - They can write code to search, filter, join, and analyze data without loading entire datasets into the model’s context window. ### Documents, Slides, and Spreadsheets - Agents can convert research into editable documents, presentations, and spreadsheets. - Outputs can remain connected to live data, update when sources change, and be exported to services such as Google Drive. ### Connected Team Applications - When static documents are insufficient, agents can create applications with interfaces, logic, and persistent state. - These apps can use connected company resources and support collaboration among multiple users. ### Deterministic Workflows - Repetitive jobs can be implemented as workflows rather than full agent sessions. - Code handles predictable steps, while models are used only where judgment is needed. - Workflows can run manually, on schedules, or in response to events. - Access to systems of record is provided through Gatekeepers, while existing MCP servers can be connected through MCP Server Portals. ## Security and Governance - Directly distributing API keys to employees or agents creates broad, long-lived access that is difficult to constrain and audit. - MCP improves credential handling by keeping keys in servers and exposing defined tools. - Tool-level control is not sufficient: agents may combine data from multiple systems, move it to less restricted locations, or expose it through apps and generated outputs. - Authorization must therefore consider not only which tools an agent can use, but also which resources it has observed and where that information can go. ### Default-Deny Access - Cloudflare Access controls entry into Cloudflare OS. - Within the platform, every agent and app begins with no permissions. - An agent must request access to a specific resource, which can be approved or denied. - Approved resources are exposed to generated code through typed bindings such as `env.PROJECT`. - These bindings represent narrowly scoped capabilities under a specific policy. - Credentials remain isolated from both the agent and the generated code. Cloudflare OS is intended as a customizable organizational platform: companies can deploy it, connect internal systems, encode their operating knowledge as skills, and give employees governed tools for building useful apps and workflows. Its default-deny, resource-aware security model is essential for safely sharing agent-generated work across an organization.

access-controlai-agentcloudflaremodel-context-protocol+3

cloudflareAug 5, 2026

WriteGuard: Fine-grained controls for MCP Servers (opens in new tab)

Cloudflare built WriteGuard to safely expand AI agents’ write access to internal MCP servers. The system centralizes authorization, risk classification, agent attribution, and auditing, addressing failures that client-side prompts or individual user vigilance cannot reliably prevent. It preserves the human user’s permissions while making each agent session identifiable and its actions queryable. ## The Risk of Uncontrolled Agent Actions - A broadly instructed cleanup agent accidentally closed thousands of tickets. - Human and agent actions were recorded under the same employee identity, making the incident difficult to investigate and repair. - Network logs could not distinguish between multiple agent sessions. - More serious failures could involve: - Amending contracts - Sending mass customer replies - Deleting database tables - Triggering destructive production actions ## MCP Fundamentals - The Model Context Protocol connects AI applications to external tools and data. - An MCP server exposes tools with: - A name - A description - An input schema - A handler that performs the operation - When an agent selects a tool, the MCP client sends the call to the server, which interacts with the downstream application. ## Cloudflare’s MCP Expansion - Cloudflare uses MCP with local clients such as OpenCode and Cloudflare OS, as well as long-running agent services. - Its internal MCP portal grew from 13 servers to 27. - Servers initially provided read-only access to systems such as Jira, GitLab, internal documentation, and operational tools. - As agents became more capable, teams requested write actions across engineering, product, design, sales, and customer success. - Cloudflare decided centralized controls were necessary because client-side skills and elicitation prompts vary across agent harnesses and can be disabled. ## WriteGuard’s Policy and Attribution Layer - WriteGuard evaluates tool configuration together with request context. - It can: - Pass a call through unchanged - Add agent attribution to supported writes - Create a scrubbed audit event - Block a call before the tool handler executes - Policies are defined per tool and include: - Risk tier - Enabled or disabled status - Labeling configuration - Risk tiers include: - **Read Only:** Search issues or inspect merge requests - **Minimal Impact:** Add reactions or mark notifications read - **Contained Write:** Add comments, create merge requests, or update issue fields - **Critical:** Merge code, deploy to production, or bulk-delete records - Labeling allows agent context to be inserted into downstream applications in formats such as plain text or HTML without modifying the MCP server. ## Preserving Human Permissions While Identifying Agents - Agents operate through the employee’s Cloudflare Access and OAuth identity. - An agent cannot perform an action its user is not authorized to perform. - Cloudflare avoided standalone agent accounts because they would create additional permissions to manage and weaken accountability. - WriteGuard supplements the human identity with MCP client and session information. - Each write can therefore be tied to both the responsible person and the specific agent session. ## Centralized, Queryable Auditing - WriteGuard classifies every invocation as successful, failed, or blocked. - It asynchronously sends scrubbed events to an internal audit Worker. - Audit records include: - MCP server and tool - Risk tier - Outcome - User and client - Request duration - Secret and sensitive input values are omitted. - Asynchronous logging avoids adding latency to the agent’s response. - MCP portal logs show raw tool invocations, while WriteGuard adds semantic classifications, agent context, and backing-service outcomes. - Central auditing makes unusually fast or widespread agent activity easier to detect and investigate. ## Recommendation Organizations expanding MCP agents beyond read-only access should use centralized, server-side policy enforcement, preserve human authorization boundaries, attach per-session agent attribution, and maintain scrubbed audit logs. Relying solely on prompts, client configuration, or undifferentiated user identities makes destructive automation difficult to prevent and even harder to understand afterward.

access-controlai-agentgitlabmodel-context-protocol+4

netflixJun 19, 2026

Data Projects: Managing Data Assets at Netflix Scale (opens in new tab)

Data Projects address Netflix’s difficulty managing millions of data assets and tens of thousands of workloads as teams and employees change. They replace asset-level permissions and human-owned workload identities with project-level grants and durable, synthetic identities. This makes access easier to maintain, workflows more resilient, and newly created assets easier to organize automatically. ## The Limits of Asset-Level Permissions - Netflix historically managed access through individual ACLs on each table. - Organizational changes required updating hundreds or thousands of permissions manually. - This overwhelmed support teams and encouraged overly broad access, such as granting access to the entire company. - The model did not scale with frequent reorganizations, team changes, and ownership transfers. ## The Limits of Human-Owned Workloads - Scheduled jobs and asynchronous workloads traditionally ran under the identity of their author. - When that person changed roles or left Netflix, the workload’s permissions changed or disappeared. - Reassigning the job to another employee often introduced new permission gaps. - This created a recurring “permissions whack-a-mole” across tens of thousands of business-critical workflows. ## Data Projects as a Management Container - A Data Project groups related tables, workflows, secrets, and other assets under one logical umbrella. - Teams manage permissions for the project instead of maintaining ACLs across every individual asset. - Grants can be assigned to users, groups, applications, and CI jobs. - Roles such as Contributor and Viewer define read/write or read-only access at the project level. ## Durable Project Identities - Each project receives a Netflix application identity and, optionally, an AWS IAM role. - Scheduled workloads execute as the project rather than as an individual employee. - The IAM role supports AWS use cases such as Spark jobs on Amazon EMR. - Privileged project members can assume the project identity from laptops or notebooks for testing and troubleshooting. - This provides a development context that matches the identity used in production. ## Gravity and Automatic Asset Organization - Assets created by workloads running under a project identity are automatically added to that project. - For example, tables created by a Maestro workflow become project assets without extra configuration. - This “gravity” keeps related outputs organized and makes future access and discovery easier. - Newly created assets inherit the project’s access model rather than requiring separate permissions. ## Securing Maestro Workflows - Maestro runs ETL pipelines, data movement jobs, machine-learning training, and other batch workloads. - As a Trusted Workload Manager, Maestro can mint identity tokens for scheduled executions. - A single workflow may be checked against table ACLs, Netflix resource policies, and AWS IAM policies. - Using a durable project identity prevents failures caused by changes to the original author’s account. - Project-scoped secrets also remain available when ownership changes. Data Projects provide Netflix with a scalable foundation for access control, workload execution, and asset ownership. Moving management from individual assets and employees to durable, team-owned projects makes the platform more stable, auditable, and resilient to organizational change.

access-controlapache-sparkidentity-managementaws-iam+4

gitlabJun 11, 2026

GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8 | GitLab Docs (opens in new tab)

GitLab released patch versions 19.0.2, 18.11.5, and 18.10.8 on June 10, 2026, addressing important security and bug fixes. Self-managed installations should upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The fixes affect both CE and EE and cover account takeover, cross-site scripting, denial of service, authorization bypasses, and server-side request forgery. ## Release Scope and Upgrade Guidance - Affected self-managed installations should upgrade to the latest patch release for their supported GitLab version. - The releases apply to GitLab Community Edition and Enterprise Edition. - GitLab publishes: - Scheduled patch releases twice monthly, on the second and fourth Wednesdays. - Ad-hoc critical patches for high-severity vulnerabilities. - Security issues are generally made public on GitLab’s issue tracker 30 days after the release containing their fix. - GitLab.com has already deployed the patches, and GitLab Dedicated customers do not need to take action. ## High-Severity Enterprise Edition Vulnerabilities - **CVE-2026-6552 — Group SAML Identity API** - CVSS 8.7. - An authenticated group Owner could potentially take over another member’s GitLab account through improper authorization. - Affects GitLab EE versions before 18.10.8, 18.11.5, and 19.0.2. - **CVE-2026-10087 — Analytics Dashboard XSS** - CVSS 8.7. - An authenticated developer could execute arbitrary client-side code on behalf of another user due to inadequate input sanitization. - Affects EE versions before the patched releases. - **CVE-2026-8589 — HTML Injection in Group Settings** - CVSS 7.3. - Improper sanitization could allow unauthorized email addresses to be added to a targeted user’s account. - Requires significant privileges and user interaction. ## Denial-of-Service Vulnerabilities - **CVE-2026-7250 — Grape API JSON Parsing** - CVSS 7.5. - An unauthenticated attacker could cause denial of service through malformed API request input. - Affects CE and EE versions dating back to 12.10. - **CVE-2026-1500 — Group Placeholder Reassignments API** - CVSS 6.5. - An authenticated user could trigger uncontrolled resource consumption with a specially crafted file upload. - Affects CE and EE versions beginning with 17.10. - **CVE-2026-10733 — CI/CD Catalog HTML Injection** - CVSS 4.3. - Improper sanitization could allow an authenticated user to disrupt the CI/CD Catalog page. ## Authorization and Data-Access Issues - **CVE-2026-6269 — Merge Requests API** - CVSS 5.4. - Developers could modify hidden merge requests because of incorrect authorization enforcement. - **CVE-2026-6277 — Security Inventory** - CVSS 4.3. - Security Managers could modify project security configuration even when the related feature was disabled. - **CVE-2026-6976 — Merge Request Diff** - CVSS 3.7. - Developers could hide changes from merge request diffs through improperly handled file names. ## Server-Side Request Forgery - **CVE-2026-9204 — Gitaly Repository Import** - CVSS 5.3. - An authenticated user could potentially read arbitrary files from the Gitaly server or access internal network resources during repository import. - The issue resulted from insufficient validation of secondary URLs. ## Recommendation Administrators of self-managed GitLab instances should upgrade to 19.0.2, 18.11.5, or 18.10.8 as soon as possible, regardless of whether they use Omnibus, source installations, or Helm charts.

access-controlgitlabci-cdapi-security+3

gitlabMay 21, 2026

Manage CI/CD credentials with GitLab Secrets Manager (opens in new tab)

GitLab Secrets Manager, entering public beta with GitLab 19.0, provides a native way to manage CI/CD credentials without storing them in broadly scoped variables or configuration files. Built on OpenBao and integrated with GitLab’s existing permissions, environments, branches, and audit trails, it aims to reduce credential exposure and simplify incident response. The post recommends trying it in existing GitLab projects and pipelines, especially where least-privilege access is difficult to enforce. ## Where CI/CD Secrets Commonly Go Wrong - Developers often store credentials in: - Project- or group-level CI/CD variables - Configuration files - Accidentally committed `.env` files - Masked CI/CD variables may still be exposed to every job and anyone with pipeline access. - Standalone vaults improve separation but introduce: - A second authentication system - Separate permission models - Additional audit logs and operational overhead ## Using GitLab Secrets Manager - Secrets are stored within GitLab’s existing project and group structure. - Pipelines reference secrets with the `secrets:` keyword in `.gitlab-ci.yml`. - By default, GitLab writes the secret to a temporary file and exposes its path to the job. - Passing a file path instead of the raw value can reduce exposure in: - Subprocesses - Crash dumps - Telemetry systems ## GitLab-Based Access Controls - Secrets use GitLab’s existing users, groups, projects, and roles. - Permissions can be assigned for reading, creating, updating, and deleting secrets. - Group-level secrets are inherited by nested projects, allowing common credentials to be defined once. - Removing someone from a project or group immediately removes their access to its secrets. - This avoids maintaining a separate access hierarchy that could drift from GitLab’s permissions. ## Job-Level Secret Scoping - Each secret can be restricted based on: - Target environment - Branch - Whether the branch is protected - Wildcards such as `production/*` simplify environment and branch rules. - Multiple conditions can be combined, such as requiring both a protected branch and a production environment. - At runtime, the backend verifies the job’s identity and scope before returning the secret. - Secrets are discarded when the job ends, and job logs are masked. - Narrow scopes reduce the systems affected if a dependency or pipeline is compromised. ## Auditing Secret Usage - Secret creation, updates, and deletions appear in GitLab’s existing audit trail. - Pipeline secret reads include the originating pipeline and job IDs. - Responders can trace where a credential was used without correlating separate systems manually. - Audit logging is available for self-managed deployments; GitLab.com support is expected during the beta. ## Public Beta Availability - The beta is available to Premium and Ultimate users on GitLab.com and self-managed deployments. - GitLab Dedicated support is planned. - The feature is free during beta and will later become a paid GitLab Credits feature. - Existing integrations with HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager remain available. GitLab Secrets Manager is best suited for teams that want least-privilege CI/CD credentials while keeping access control and auditing within GitLab. Teams can adopt it incrementally alongside existing external secrets platforms.

access-controlci-cdsecrets-managementaudit-logging+3

figmaOct 22, 2025

Visibility at Scale: How Figma Detects Sensitive Data Exposure | Figma Blog (opens in new tab)

The provided content includes only the title, “How we built a custom permissions DSL at Figma,” and category labels. It does not contain the blog post’s body, so there is not enough information to accurately summarize its technical arguments, implementation details, or conclusions. Please provide the full article text or a link to the post.

access-controlauthorizationinfrastructuredsl+2

discordApr 16, 2025

The Game Developer Playbook, Part One: Getting Started on Discord (opens in new tab)

Discord’s playtest community should be created early in development to build relationships with players, gather feedback, and develop trusted advocates. The article recommends keeping the server focused on testing and feedback, with a clear structure separating information, discussion, staff communication, and playtest voice channels. A simple server template can evolve as the game and community grow. ## Getting Started - New server owners should understand Discord basics, including: - Creating and setting up a server - Managing permissions and roles - Sharing screens - Starting early gives developers more time to nurture a small but valuable group of engaged players. ## Playtest Community Basics - The primary goals should be to: - Make it easy for players to test the game - Give testers clear ways to provide feedback - Keep the community’s scope focused - Developers can begin with Discord’s recommended server template and expand it over time. ## Categories and Server Organization - Organize channels into clear groups: - Read-only information - Two-way discussions - Staff-only communication - Individual voice channels for voice chat, video, and screen sharing - Keep important information—such as rules, announcements, and updates—at the top. - Games with many classes, heroes, kits, or complex mechanics may benefit from dedicated forum or discussion channels. ## Roles and Permissions - Use two primary roles: - `@admin`, later renamed for the studio - `@playtest`, assigned to testers - Studio members should access every channel, while testers should see everything except the admin-only category. - Remove permissions from `@everyone` so unassigned users see an empty server, even if they enter through an unauthorized invite. - Use Discord’s **View Server As** feature to verify what each role can access. ## Community Features - Enabling Discord’s **Community** features can help larger servers manage growth. - Useful options include: - **Announcement Channels** for publishing updates that other servers can follow - **Server Insights** for engagement and retention data once the server reaches 500 members - **Community Onboarding** for self-assigned roles and rule acceptance - These features do not need to be enabled immediately; developers can adopt them as the community expands. ## Channel Design - Every channel should have a clearly defined purpose and a descriptive name. - Read-only channels should use consistent formatting, emojis, and Markdown to make important information easy to scan. - Suggested channels include: - `#rules-and-info` for server rules and guidelines - `#announcements` for game and playtest news - `#patch-notes` for updates and release details - `#game-discussion` for broader conversation A successful game playtest server should start small, organized, and purpose-driven. Establish clear permissions, separate information from discussion, and add features or channels only when they support the testing process and the community’s growth.

access-controldiscordmarkdowngame-development+2

figmaJun 2, 2024

Updates to how drafts work | Figma Blog (opens in new tab)

Figma is moving Drafts for Starter and Professional users into team-associated spaces. The change is intended to clarify ownership, permissions, security, and plan features while keeping drafts private and free to create or edit. Users must eventually move existing drafts into a team, though no immediate deadline applies. ## Why Figma Is Changing Drafts - Drafts previously existed outside teams, creating: - Unclear ownership and team association - Inconsistent behavior across Figma plans - Limited access to paid features such as advanced prototyping, password protection, and Dev Mode - Ambiguous permissions between personal and professional work - Potential security, intellectual-property, and file-loss risks ## New Drafts Structure - Every draft must now belong to a team. - Each team provides members with a private drafts space. - Drafts in Professional teams can use Professional features when edited by eligible users. - Collaborators who are not full team members will be changed from editors to viewers when a draft moves, preventing unexpected paid seats. - Users with one Starter team may have their drafts migrated automatically. ## What Remains the Same - Drafts remain private to their owner and invited collaborators. - Users can create and edit personal drafts for free. - Starter teams can have unlimited viewers and unlimited editors on up to three collaborative files. ## Moving Existing Drafts - Users will find their files in a temporary “Drafts to move” space. - Drafts can be moved into any existing team or into a newly created free Starter team for personal work. - Existing collaborators can continue editing before migration, but new collaborators can only be added after moving a file to a team. - There is no hard deadline yet; unmoved drafts will eventually be transferred to a new free Starter plan after advance notice. ## Future Billing and Collaboration Improvements - Figma plans to make paid editor-seat upgrades clearer. - Planned improvements include better freelancer handoffs, support for users on multiple teams, license management, admin tools, and guest management. - The company is also redesigning its core billing experience. Figma recommends organizing drafts into the appropriate team—or creating a free Starter team for personal projects—to establish clearer separation between professional and personal work.

access-controlfigmaprototypingdev-mode+2

figmaMar 12, 2024

How We Built a Custom Permissions DSL at Figma | Figma Blog (opens in new tab)

Figma’s original permissions system—a large Ruby `has_access?` method in its monolith—became too complex, risky, and expensive to maintain. As collaboration features expanded, permission rules involving roles, links, hierarchies, organizations, billing, and deleted files caused bugs, delayed projects, and heavy database load. Figma responded by building a custom permissions DSL and cross-platform logic engine to make rules more modular, flexible, performant, and easier to debug. ## Why Permissions Became Difficult - Figma’s collaboration model requires detailed access rules for files and other resources. - Access can come through: - Roles inherited from parent folders, teams, or organizations - Link-sharing settings - User roles and authorship levels - Passwords, expiration periods, and organization restrictions - Originally, permissions lived in a Ruby monolith using ActiveRecord. - A model-level `has_access?` method accepted a user and resource, performed database queries, and returned a Boolean. - Product engineers had to call this method correctly from controllers. ## Problems with the Original System ### Complex Logic and Difficult Debugging - `has_access?` methods grew into long functions with many optional parameters. - Engineers were reluctant to modify them because mistakes could expose access to large numbers of files. - All permission logic for a resource was intertwined, making it difficult to isolate or test individual rules. - Debugging often required adding many print statements and understanding the entire permissions implementation. ### Inflexible Hierarchical Permissions - Permissions were nominally represented by hierarchical integer levels, such as edit access being higher than view access. - Boolean flags introduced exceptions that undermined the hierarchy, including options such as: - `ignore_link_access` - `org_candidate` - `ignore_archived_branch` - A user could have a higher access level but fail a lower-level check when a flag changed the behavior. - These flags differed between resources, forcing engineers to remember numerous special cases. - Figma needed granular, non-hierarchical permissions that could operate independently or define new permission hierarchies. ### Excessive Database Load - As Figma scaled, permission checks accounted for roughly 20% of database load. - This created a serious scalability concern because database capacity had physical limits. - Although the database team was pursuing vertical and horizontal sharding, Figma also needed to reduce and better control permission-related queries. ## Building a Custom Permissions DSL - Figma generally prefers adopting open-source or commercial solutions, but existing options did not adequately address its requirements. - The company chose to build: - A domain-specific language for expressing permissions - A custom cross-platform logic engine - A migration plan for moving critical permission rules into the new system - The intended result was a permissions system that improved developer ergonomics while increasing correctness and performance. Figma’s experience shows that permissions can become a foundational scalability and reliability problem when implemented as one growing authorization function. A dedicated, composable DSL can provide clearer rules, more flexible access models, and better control over database usage.

access-controlrubydatabase-shardingauthorization+3

figmaNov 28, 2017

Advanced Project Permissions for design systems | Figma Blog (opens in new tab)

Figma introduced Advanced Project Permissions to give design-system teams finer control over who can edit or access projects. Available to paying Professional Teams, the feature adds view-only and invite-only options alongside the existing team-wide editing model. It is designed to protect systems from accidental changes while allowing maintainers to develop and test privately. ## Why Design Systems Need More Control - Design-system maintainers often need to work privately before releasing components to the broader organization. - Once published, the system should be protected from accidental edits by designers who primarily consume its components. - Figma’s Team Library enabled cross-file and cross-team component sharing, but additional project-level privacy and access controls were needed. ## New Project Permission Options - Professional Team editors can choose one of three access settings when creating a project: - Everyone on the team can edit - Everyone on the team can view - Invite-only access for selected collaborators - Existing projects can be updated by opening the **Share** dialog and changing their permissions. - The feature creates a boundary between design-system “maintainers” and “viewers.” ## Effects on Team Workflows - View-only permissions reduce the risk of well-intentioned team members modifying carefully maintained components. - Invite-only projects allow maintainers to experiment and refine a system before wider deployment. - Larger teams may give individual designers fewer opportunities to directly change the system, depending on the balance between maintainers and viewers. - Figma was exploring pull-request-like workflows so designers could suggest changes while maintainers retained ownership. Overall, the permissions provide a practical foundation for managing robust design systems: restrict editing to maintainers, use view-only access for consumers, and consider structured contribution workflows for future improvements.

access-controlfigmadesign-systemscollaboration+2