By Kat Traxler —

A Security Constitution at Work

A Security Constitution at Work

Models are good at what they are trained to do. The field taught machines what a security bug looks like by compiling vulnerability details into datasets such as BigVul and CVEfixes and training models on those patterns. That training is why Google's Big Sleep found a memory-corruption bug in SQLite that fuzzing had missed, and why a 16-year-old flaw in FFmpeg fell to a model after automated testing had hit that line five million times. In 2026, we put LLMs on the front line of open-source security to great fanfare.

Today I am publishing a sample set of a different kind of bug, found by my agentic harness. None of them has a bad line. Each is an insecure-by-design flaw: a missing or inadequate control that rises to the level of a security vulnerability.

A bug can sit in code yet never be executed, but a flaw lives in the design. Gary McGraw drew that distinction in 2014, when he estimated that half of security defects are flaws, not bugs. Flaws get less attention, he argued, because the bug problem is easier: we have technology for addressing bad lines of code en masse.

Each of the cases below is a check that should exist and does not:

  • A managed identity that acts without asking whether the caller has permission.
  • A shared service connects to a caller-supplied private network without checking who owns it.
  • An endpoint returns credentials in plaintext, confusing control-plane access with data-plane access.
  • A managed service delivers a stored password to a server the caller controls.
  • A platform lets an editor run as any identity in the project, an unauthorized delegation.

These are much trickier to write signatures for. Grepping for an absent control is a complex problem; you can only see what is missing if you know what should be there. In my harness, that knowledge is retained in the Security Constitution. Its job is to give the model a written view of how a multi-tenant platform should hold trust, so that when the model reads an API reference, or any attack surface, it can spot where the platform falls short of the expected security guarantees.

A security-alignment layer

This is not a post about a bug-hunting harness. It is about novel candidate generation, specifically, how I used a Security Constitution as a security-alignment layer when a model evaluates an attack surface. Moving a bug from identification to submission is ordinary harness plumbing. The more interesting question I sought to answer is: where do candidates come from, and how do you get a model to look for something it has never seen?

That's how the idea of a Security Constitution came to be. In my harness, it sits between the model and the attack surface. It does not tell the model what to do. It tells the model what should be true.

My Security Constitution has three parts:

  • Twelve principles on how a multi-tenant platform should hold trust.
  • Eleven operational lessons on how to be wrong less: how to tell a design flaw from a powerful feature, when a confused deputy is really confused, and what counts as evidence.
  • Thirteen anchors of trust, the things a platform can root an authorization decision in: who the caller is, what a name resolves to, who owns the acting identity, and where the traffic comes from.

When the model reads an API reference through that layer, it does not match bug signatures. It compares what it reads against what should be true, and the gap is the candidate.

In the harness, the constitution sits at the top of the funnel. It produces candidates, each tagged with the principle it would break. Everything downstream- proving or disproving, adversarial review, the live test against a real tenant, the report, is standard vulnerability discovery plumbing. The cases below came out of the front of the funnel.

Case studies

All of these cloud services are public and well-covered attack surfaces. Vertex AI and BigQuery are two of the most scrutinized services on Google Cloud. However, I looked at them through a new lens: the 12 principles and 11 operational lessons of the Security Constitution. Each case below opens with the principle that found it.

Principle 1: Authorization at every trust boundary

Every time a request changes hands to a different identity, system, tenant, or resource, the platform should check authorization again. A boundary exists wherever the acting principal changes, and the easiest place to lose the authorization thread is where a service's own identity picks up the caller's request and carries on.

1. Vertex AI: Confused Deputy

The caller starts with an ordinary Vertex AI user role and no access to the bucket in question. By leveraging the functionality of the service and the automatic permissions assigned to the Vertex AI Service Account, the caller can both read and write to all GCS buckets in the project, without any Storage permissions.

This confused deputy scenario is Principle 1 at its plainest. The acting principal changed from the caller to a Google-managed identity (P4SA), and the initial caller's authorization was not checked.

Principles 11 and 12: Network resources are protected resources, and cross-service authorization completeness

  1. Accessing a network is a privileged act, and a network the caller names must be authorized like any other resource.
  2. When a request crosses two services, one of them must own the check on the caller, or the boundary fails open.

2. BigQuery Data Transfer Service: Network-based Confused Deputy

In this scenario, an attacker can point a transfer configuration at a network attachment in another tenant’s project. The shared Data Transfer connector fleet then establishes presence inside that tenant’s VPC and reads a private database. Nothing checks that the caller may use the attachment. The disclosure timeline, the victim-side preconditions, and Google’s response are in a separate post.

Principle 1 pointed the model at this confused deputy, but the finding exposed two angles no principle covered, and both went back into the constitution as principles of their own. Principle 11: network and connectivity resources are protected resources, and a confused deputy can target them just as it targets data. Principle 12: when a request crosses two services, one of them must own the authorization check.

Principle 7: Credential lifecycle governance

Every long-lived credential must stay under its administrator's governance for its whole lifecycle: enumerable on demand, bounded in issuance and lifetime, and definitively revocable. A path that carries a credential out of that control breaks the lifecycle, whatever the path is called. Two cases, both on Azure: one where nothing walled off the credential, and one where the platform built the wall and then delivered the credential around it.

3. Azure DevTest Labs: Plaintext Credentials

In DevTest Labs, a caller starts with the Reader role on a lab, a control-plane role meant to inspect configuration and nothing more. By reading a formula through the Azure Resource Manager API, the saved template a lab uses to stamp out virtual machines, the caller receives the VM administrator password in cleartext. The portal treats that field as write-only. ARM returned it anyway.

This is Principle 7 in its simplest form. A VM administrator password is a long-lived credential that belongs under the administrator’s governance, and here any Reader could read it. The constitution’s part was the multiplier. The first instance of this shape appeared on a different cloud in June. I codified it as a signal, a secret field in a read response guarded by ordinary read permission, and the model then found fourteen more instances across three clouds. DevTest Labs was one of them.

4. Azure Managed Grafana: Credential Redirect

In the case of Managed Grafana, a caller could start with configuration-write access to an instance and no secret permissions. The platform redacts the SMTP password on read and denies direct calls to retrieve it. But by updating the SMTP host and leaving the stored password in place, the caller could direct the managed Grafana fleet to deliver the unredacted password to an endpoint of the caller’s choosing.

This is Principle 7 at work again. The platform enforced a boundary by restricting direct reading of the SMTP password, but then provided a mechanism that hands the credential to anyone who can edit a hostname. No prior art described a credential redirect; instead, the model proposed it as a distinct shape, and the reasonable-customer test let this candidate graduate from possible feature abuse to insecure-by-design flaw.

The reasonable-customer test

Here is where a model usually stalls, thinking: “this might be intended.” The reasonable-customer test breaks the stall by asking what a reasonable, security-conscious customer might expect.

“Would a reasonable customer be alarmed to learn that a configuration editor who cannot read the stored SMTP password could redirect it and read it by choosing where it is delivered?"

Yes. The platform had already proven an Editor cannot read that password directly. Delivering it to a host the Editor chose contradicts the platform’s own promise. Design flaw.

Principle 8: Bounded blast radius for delegation

When one identity may act as another, that delegation must be bounded and explicitly authorized. Every cloud gates attaching an identity to a resource: Google Cloud with the actAs permission, Azure with the assign action. A delegation nobody authorized is a design flaw.

5. Integration Connectors:  Privilege Escalation

In Integration Connectors, a caller starts with editor rights on the service and no permission to use or .actAs any service account. By creating a connection and naming a service account as its run-as identity, the caller can run code as any service account in the project, resulting in privilege escalation. The reportable flaw is the missing check: the service never confirms the caller holds .actAs on that service account, the check Google Cloud enforces everywhere else before binding an identity to a resource.

This is a Principle 8 violation: a delegation must be bounded and explicitly authorized, and a delegation nobody authorized is a design flaw. The gate exists, the platform enforces it on its other binding methods, and this service skipped it. The order of discovery is the point. The constitution named the control, the model read the Connectors API reference and flagged every method that takes a caller-supplied run-as account, and the bug followed.

Feature abuse, or a design flaw?

Every candidate the harness generates must clear one question before graduating: is this just a powerful feature working as designed or a missing control? From the outside, the two can look similar. The constitution draws the line this way:

Feature abuse. Someone uses a legitimate capability maliciously, but the authorization checks, logging, administrative controls and guardrails exist and work. The platform recognized the risk and mitigated it. A project Editor doing Editor things is not a finding, however alarming the blast radius might be. Nor is a deputy whose every grant the customer made can see and can revoke. That is documented role composition, and the customer consented to it.

Insecure-by-design flaw. The feature works as designed, but the design lacks a control a reasonable customer would expect or the platform's behavior contradicts what it told the customer.

The reasonable-customer test, Lesson 5 in the constitution, adjudicates. Write the customer's documented expectation as one sentence. Write the access actually achieved as one sentence. If the two contradict, it is a design flaw. If you cannot write the contradiction, you have a mechanism, not a finding.

The test does not replace technical analysis. It cuts complexity for the cases where the authorization chain is convoluted and the customer's expectation is simple. In the harness, it runs after the mechanism is understood and before any money goes into proving it. Candidates that pass get a proof of concept and a live test. Candidates that fail get parked as documentation signal. The two sentences then become the hypothesis the live test must prove: the baseline the role is documented to reach, and the delta it actually reached. Hypothesize statically, validate by execution.

The test also travels well into a vendor's triage queue, because it moves the argument from the engineer's terms to the customer's. When the authorization chain takes a diagram to explain and the expectation fits in one line, the one line is the part the vendor cannot argue with. In the Grafana case, the platform had written the expectation itself.

By The Numbers

These five cases are a sample of a corpus of over a hundred issues; to date, four in ten are still open and in triage.

  • 109 bugs filed across three cloud providers, in about three months of hunting.
  • 11 ruled working as intended. Most lean more toward feature abuse rather than insecure-by-design.
  • 98 real issues remain.
  • 53 accepted: This number includes rewarded, not rewarded issues, fixed, not fixed, and duplicates. All submissions that were acknowledged to be a security issue.
  • 45 still in triage: Either still awaiting triage, awaiting a determination from the program, or a handful that are in dispute.

I found every one by reading the API reference documentation, and I reproduced every one against live infrastructure before filing.

What I'm Releasing

Everything you need to apply the Security Constitution to your attack surface. It includes:

  • The Security Constitution in full: the twelve principles, the eleven operational lessons, and the Anchors of Trust.
  • The taxonomy behind these cases: five worked shapes, the discovery signals that route to them, and the feature-abuse negatives they calibrate against.

Refer to: Security Constitution on Github

Remember, the Security Constitution is an alignment layer, not a scanner. It contains enough to put a point of view in front of your own model. Usage might look like:

Anchor yourself in the principles outlined in the Security Constitution. From that view of the world, review this service and generate new candidates to hunt for insecure-by-design flaws.

Then make every candidate pass the reasonable-customer test before you spend on live infrastructure proving it, and validate by execution before you file.

Your harness does not need more scaffolding. It needs a point of view.