TENANTPROOF

GitLab Duo-powered autonomous security repair: detect cross-tenant access regressions, verify the fix with CI, and safely deploy with runtime evidence.

Comment

Inspiration

A green pipeline does not always mean a safe release.

In a multi-tenant SaaS application, one of the most important security guarantees is simple: Customer A must never access Customer B's data. Yet conventional unit tests can pass even when a small authorization regression breaks that guarantee.

We built TENANTPROOF around one question:

What if a GitLab merge request had to prove that tenant isolation still works before its changes could reach production?

Instead of trusting an AI-generated security assessment, we wanted executable evidence, an actual GitLab Duo repair, an independently enforced release policy, and verification against the deployed application.

What it does

TENANTPROOF is an evidence-driven security repair and release workflow built with the GitLab Duo Agent Platform.

It uses a small, synthetic multi-tenant invoice API to demonstrate how a dangerous authorization regression can be detected, repaired, verified, and safely released.

The canonical demonstration follows a real GitLab merge request:

  1. Introduce a controlled regression. A deliberately vulnerable change removes the tenant restriction from an invoice query. Ordinary unit tests pass, but the isolation gate fails: an authenticated user can access another tenant's invoice.
  2. Repair with GitLab Duo. A custom agent workflow investigates the failed pipeline, identifies the missing tenant predicate, and pushes a focused corrective commit.
  3. Verify independently. GitLab CI runs the required tests against the exact corrected commit.
  4. Enforce release policy. A protected controller checks the agent's attestation, commit SHA, original failure, required successful jobs, and allowlisted final diff. It fails closed when evidence is incomplete.
  5. Merge and deploy. Once all conditions are satisfied, the controller merges the MR. A protected main pipeline builds and deploys the application to Google Cloud Run.
  6. Prove the deployed behavior. Real HTTP probes confirm that authorized requests still succeed, cross-tenant requests are forbidden, and unauthenticated requests are rejected.

The defining moment

Before repair: conventional tests pass, but a cross-tenant request incorrectly returns HTTP 200.

After repair and deployment: the same class of cross-tenant request returns HTTP 403, while legitimate access still returns HTTP 200.

The recorded deployment checks returned:

Check HTTP status
Health endpoint 200
Tenant A → own invoice 200
Tenant A → Tenant B invoice 403
Tenant B → own invoice 200
Tenant B → Tenant A invoice 403
Unauthenticated request 401

These results come from an actual deployment verification job, not a simulated dashboard.

How we built it

TENANTPROOF combines a deliberately small application with a carefully controlled post-code automation pipeline.

Application and security contracts

  • Python, FastAPI, SQLAlchemy, and PostgreSQL power a synthetic two-tenant invoice API.
  • JWT-based authentication and tenant-scoped authorization establish the security boundary.
  • Pytest runs conventional application tests and independent cross-tenant isolation tests.
  • Two controlled regression families were evaluated: a missing SQL tenant predicate (M01) and a tenantless cache key (M02).

GitLab Duo Agent Platform

A custom GitLab Duo workflow is activated through merge-request reviewer assignment. The agent investigates the actual failure, modifies the application source, commits the correction, and records evidence of its work.

GitLab CI/CD and release governance

GitLab pipelines execute contract checks, isolation tests, unit tests, security checks, packaging, and deployment verification.

A protected Python controller independently evaluates the exact corrected SHA, required passing jobs, agent attestation, MR state, and final diff before authorizing the narrowly scoped synthetic release.

The agent does not have independent authority to merge or deploy.

Google Cloud deployment

The protected release pipeline deploys to Google Cloud Run, using GitLab OIDC and Workload Identity Federation for Google Cloud authentication. Runtime checks produce an HTTP evidence artifact for the deployed revision.

Challenges we ran into

Making a security failure observable. A passing unit-test suite was not enough. We had to construct an isolation contract that would fail when a foreign tenant's invoice became accessible.

Separating AI remediation from release authorization. A plausible agent explanation cannot be the authority for a production release. The independent controller must verify objective evidence before proceeding.

Handling real agent execution failures. An initial GitLab Duo session ended without producing the required output. We reassigned the reviewer to trigger a fresh session, which successfully diagnosed and corrected the regression.

Preventing unsafe automation. The release controller had to recognize a narrowly defined synthetic scenario, enforce an exact SHA and file allowlist, and stop when prerequisites were missing.

Proving the deployed revision. A successful build or healthy endpoint alone would not prove tenant isolation. We added authenticated cross-tenant HTTP checks after deployment.

Accomplishments that we're proud of

1. A real GitLab Duo security correction. On merge request !11, GitLab Duo session #9907282 identified the missing tenant restriction and pushed a corrective source commit.

2. An independently verified fix. The original vulnerable pipeline failed the isolation gate, while the corrected pipeline passed the required checks.

3. A policy-controlled automatic merge. The protected reconciliation controller recorded MERGED only after validating the required evidence.

4. A completed cloud release. The post-merge pipeline deployed the corrected application to Google Cloud Run and recorded six successful HTTP assertions.

5. Two distinct regression mechanisms. In separate trials, GitLab Duo repaired both a missing SQL tenant predicate and a tenantless cache-key defect.

6. An auditable execution trail. The repository preserves the merge requests, agent session, corrective commit, CI history, controller result, deployment evidence, and reproducibility instructions.

Explore the evidence

What we learned

Security claims need executable evidence. An LLM can help repair a defect, but independent tests must determine whether the repair is acceptable.

Autonomy works best with explicit boundaries. A narrowly scoped, fail-closed release controller makes an autonomous workflow more inspectable and safer than an unrestricted agent with deployment privileges.

Production verification matters. A successful merge is not the end of the story. The deployed revision must still satisfy the security contract.

Agent reliability is part of system design. The initial failed session showed why retries, observability, and recovery paths matter.

Scope and limitations must remain visible. Our Hands-off demonstration is a controlled synthetic rehearsal using pre-existing isolation tests and a strict release allowlist. It does not establish universal autonomous vulnerability discovery or unrestricted production security repair.

What's next for TENANTPROOF

We want to evolve TENANTPROOF from a controlled demonstration into a reusable security-boundary verification workflow.

The next priorities are:

  • Generate additional security probes for new endpoints and authorization changes.
  • Extend coverage beyond SQL queries and cache keys to other multi-tenant failure modes.
  • Improve agent failure recovery and structured evidence provenance.
  • Generalize policy evaluation without granting agents unrestricted merge privileges.
  • Add safer deployment promotion, rollback, and ongoing verification.
  • Measure remediation reliability, execution time, and operational cost across repeated trials.

TENANTPROOF's goal is not to make AI the final authority on security. It is to let AI repair code while independent evidence decides whether that code is safe to ship.

Built With

Share this project:

Updates

Submission history