Senior Software Engineer (Ruby), Security Platform: Authorization

An overview of this role

As a Senior Software Engineer on GitLab's Authorization team, you will own significant parts of the system that decides what every user, token, and automated agent can access on GitLab.com, Self-Managed, and Dedicated.

Today that work is Ruby on Rails. Roughly 400 policy classes and a YAML catalog of about 1,900 permissions sit behind every API request. You will work on the permission model itself (fine-grained token permissions, custom roles, and the GraphQL and REST surfaces that enforce them). You will also help move that model onto GitLab's next-generation authorization stack, which pairs the Rails monolith with a Rust policy engine using Zanzibar-style relationship tuples and Cedar policies. The monolith already loads that engine in-process and can reach it over gRPC.

Some examples of our projects:

• Refactoring GitLab's policy layer so the same permission definitions can be evaluated by the monolith and by our new authorization service
• Extending fine-grained token permissions to more resources and more kinds of principal, including the service identities behind AI agents

What you'll do

• Design and ship authorization changes in GitLab's Ruby on Rails monolith, where a single request can trigger hundreds of permission checks.
• Own a workstream end to end. Problem definition through feature-flagged rollout, dual-run verification, and cleanup.
• Build and extend fine-grained permissions for tokens and roles, and keep the permission catalog coherent as it grows.
• Extend and harden authorization enforcement across GraphQL and the REST API.
• Refactor long-lived policy code so both the monolith and our new authorization engine can evaluate it, without changing behavior for existing customers.
• Improve the reliability, performance, and security posture of existing authorization systems, including paying down permission-model debt.
• Partner with the authentication, platform, AI, and modular-service teams on interface contracts as authorization moves toward a shared service.
• Drive technical decisions in writing. Design docs, architecture decision records, and code review, in a fully asynchronous organization.

What you'll bring

• Significant experience building and operating production Ruby on Rails applications.
• Experience designing or implementing authorization systems, including role-based access control and fine-grained permissions.
• A security mindset. You treat a permission bug as a security bug, and you reason about blast radius before elegance.
• Comfort making careful changes to large, long-lived codebases. Incremental refactors, feature-flagged rollouts, and migrations that must not change behavior for existing users.
• Working knowledge of GraphQL and API authorization patterns.
• Attention to performance at scale. You understand why one uncached check matters when it runs hundreds of times per request.
• Preferred: hands-on PostgreSQL experience.
• Strong written communication. You are effective when most decisions happen in a document or a merge request rather than a meeting.
• Helpful but not required: Rust, gRPC or Protocol Buffers, Cedar or other policy languages, Zanzibar-style authorization systems, Go, or service-oriented architecture. Several engineers on this team picked up Rust for this work and we will support you doing the same.
• We welcome transferable experience from adjacent domains such as identity, policy engines, and platform security.

About the team

The Authorization team owns the capabilities that determine what users, tokens, and automated agents can access across GitLab. Our work runs on two tracks. We are strengthening the permission model inside the Ruby on Rails monolith (fine-grained token permissions, custom roles, and the policy layer that enforces them), and we are moving that model onto a shared authorization platform built for GitLab's modular and cell-based future.

We work closely with the teams building GitLab's authentication layer, its Rust authorization engine, and the first modular services adopting it. The team is small, distributed across time zones, works in the open, and makes its decisions in writing.