How a rating is made

Standard 0.2 beta · published for review · every rating here is experimental

A GAMMA-Ray rating is a public reading of public evidence, in the tradition of the public ratings of websites' encryption and of companies' security posture: every input is linked, the rules are published, and anyone can check the arithmetic or correct a fact.

The label

This is what a rating looks like when it is shown somewhere else. One for each of the 5 scans so far:

• The large number is the level the agent is held at: the freedom its evidenced governance supports. For a product it is the range of freedom across its configurations, because a product is not held at anything until it is deployed.
• The lines beside it are never left off: what it reaches, its governance, its grant, and what is on its work order.
• Beta rating stays on the label until the standard leaves beta.

The steps, on one example

The example is RiskMandate Publisher, one of our own agents, because its grant and its mandate are both published.

1. Say what is being rated. One agent in one deployment. For a product, which configuration.

2. Answer the questions. 21 questions, 72 indicators. Each answer is a yes with a source, the date read, and how it is known. No evidence means "not evidenced", never "no".

3. Decide which answers count. A fact is one of two kinds:

• a statement fact: publishing it is the evidence. A purpose written down, an owner named, a policy published.
• an operation fact: it has to be true while the agent runs. These count only when they are observed or measured. If they are only stated, they are shown as claimed and do not raise a level.

There are 11 operation facts:

• I23 What it can reach is enumerated: scopes, permissions, tools. Read from a grant profile only: a description of permissions in prose does not count.
• I28 Its tokens are bound to the service they were issued for and are not passed on.
• I41 Its actions are logged. The log must cover what the agent does (its tool calls, commands or commits), not only what is released.
• I42 The log is tamper-evident and kept for a stated time.
• I43 It is monitored in operation. Somebody or something must be shown to look at the record while the agent runs: a dated report, an alert, a review.
• I44 Anomalies are detected in real time and raise alerts.
• I45 A limit on it is enforced by something outside its own reach. Read from a measured grant only. It holds when every capability in the grant whose effect cannot be undone sits behind a boundary.
• I48 Policy is enforced as machine-readable rules.
• I51 It is tested for safety and security, including by attack. The agent itself must be tested, including by attack. Scanning the code or content it produces is a different fact.
• I62 Third-party components are monitored and have risk controls.
• I64 Compliance evidence is produced continuously, ready for a regulator.

Some other facts have a scope note, so that a near miss is not credited:

• I12 Several agents coordinate inside the organisation. Agents that each have their own context and authority and pass work between them. One agent delegating a side task inside its own session does not count.
• I34 A governance policy for agents is published. A policy that is in force for this agent. A product feature that lets an operator deploy rules is a mechanism, not a policy.
• I49 The difference between what it can reach and what it is for is stated. Needs both a mandate and a grant. Without a written mandate there is no delta to state.
• S1 It is in production: a public source names a customer or gives usage figures for what it does on its own. A public source has to name a customer, or give usage figures, for the capability that acts. A demonstration or a roadmap does not count.
• S2 Others build on it: third parties publish integrations, skills or agents for it. Third parties, not the vendor, publish the integrations, skills or agents.
• S3 It is machine-readable for agents: it publishes an llms.txt, an AGENTS.md, an API description or an agent card. Checked by fetching the file: an llms.txt, an AGENTS.md, an OpenAPI description or an agent card that resolves.

4. Compute freedom. From the first five questions: what it is built on, whether it acts, how far it reaches, whether it works with other agents, and the person's role. The Publisher reaches level 5.

5. Measure the grant. What its permissions actually let it do, capability by capability, with the barrier in front of each. This is RiskMandate's measurement.

6. Compute governance. Each level is a pattern over the indicators. Two of them are read from the measured grant and never from words: that the grant is enumerated, and that every capability whose effect cannot be undone is behind a boundary.

7. Hold the level. The agent is held at the lower of the freedom it reaches and the freedom its governance clears.

The filled dot is what the evidence supports. The hollow dot is where the agent's own statements would put it.

8. Write the work order. Most consequential first: capabilities the mandate refuses that are in the grant anyway; capabilities that cannot be undone and are not bounded; then the evidence the next level is missing.

9. Issue the label, and put everything in a vault. The rating, its evidence list and its grant go into a public vault whose read key is on the rating's page.

The deployment matters: the matrix

The same product is a different agent depending on how it is set up. So a product is rated per configuration, and it gets no governance level: that belongs to whoever deploys it.

Claude Code on the web

Claude Code, on your own machine

GitHub Copilot cloud agent

The deployments rated so far:

What changed from the last version, and what moved

The rules changed after an outside review of site v0.0.2. Three changes:

1. Evidence has to be eligible. Operation facts count only when observed or measured.
2. A boundary has a scope. One bounded capability no longer satisfies "bounded". Every capability that cannot be undone has to be behind a boundary, read from a measured grant.
3. A product has no governance level. It has configurations.

Four answers in the product examples were wrong and were removed or corrected. All 5 scans were then replayed:

What a rating is not

• Not a certification, an audit or a security review.
• Not a judgement of a vendor. A product example says what the product does and controls as documented.
• Not final. This is a beta. The mapping behind the questions has had one reader, the level rules are a draft, and a rating will move when they do.

To correct a fact in a rating, the page of each rating names its sources; the repository is public.