How the Agent Posture Score is calculated
RosmarOps reads the configuration of your AI coding agents and draws an exposure map: what each agent can read and change, which keys it can reach, and whether one agent can change another agent's configuration or instructions. The Agent Posture Score turns that map into a number out of 100. This page is the whole method. Nothing in it is secret.
One score per agent
RosmarOps gives each agent it evaluates its own Agent Posture Score, out of 100. Higher is better.
The band comes from the traffic light
The score never contradicts the agent's own traffic light, because that agent's worst finding sets the band and the score moves inside it:
- 0–49, red: Exposed.
- 50–79, yellow: Open gaps.
- 80–100, green: Contained.
A 79 is not "nearly fine". It still has gaps.
What each finding weighs
Red findings:
- a high-privilege credential the agent can read and send out: 20;
- being able to change another agent's configuration: 15;
- being able to change its own configuration: 15;
- a high-privilege credential saved in a git repository: 20, or 30 if that repository has a remote.
Yellow findings:
- a medium credential it can read and send out (or one RosmarOps can't classify), or a high-privilege one it can only read: 8;
- another agent's instructions it can rewrite: 6;
- its own instructions: 4;
- a medium credential saved in git: 8.
If a credential finding reaches any project, not just one, its weight is multiplied by 1.5. A credential in git counts in every agent's score, because it doesn't depend on any agent. Medium credentials an agent can read but has no way to send out aren't findings, but each adds 2. Low-privilege keys, such as publishable or anonymous keys, and template values weigh nothing.
Two things don't change the weight. Confidence doesn't: when RosmarOps has to assume something, it says so, but an assumption doesn't make the exposure lighter. And the number of copies doesn't: the same finding in 27 projects weighs the same as in one, because how far it reaches is already counted.
The formula
Add up the weights: that's P. Inside the band, the score falls as P grows:
score = bottom of the band + width of the band × 80 / (80 + P), rounded down.
The widths are 49 for red, 29 for yellow and 20 for green. That has three consequences:
- fixing something never lowers the score, and adding a problem never raises it;
- because it's rounded down, a small fix doesn't always change the number when a lot is left;
- 100 only happens when nothing was found.
A synthetic example
An agent with four findings:
- a high-privilege credential reachable from any project (30);
- write access to another agent's configuration (15);
- a medium credential reachable from any project (12);
- its own instruction files (4).
P is 61, the band is red, and the score is 27. Fixing the first one alone takes it to 35. Fixing everything takes it to 100.
When there is no score
An agent only gets a score if RosmarOps could read everything it needs for that agent:
- the capability graph was built and validated;
- the run didn't time out while building it;
- none of that agent's configuration sources failed to read;
- no file failed to read in a way that could hide a credential.
If any of those fails, the report says "No score" and gives the reason. An agent RosmarOps doesn't know how to evaluate yet isn't scored at all: the report lists it as detected, not evaluated yet. With no agents on the machine, the report says "No score: no AI agents found", never 100.
Which fixes count
The score only moves when RosmarOps runs again and reads the new configuration. A fix that removes the exposure takes its whole weight off the score. A fix that narrows a credential finding from any project to one project keeps the finding but drops the ×1.5. If a setting narrows the exposure but, according to the vendor's own documentation, doesn't close it, the score doesn't move. The report says what is left instead.
Before you change anything, the report tells you how much the score would rise if you made today's suggested change.
Versions and comparisons
The formula is versioned. The report keeps the method version next to every score, together with the versions of the detection rules and of the knowledge base it used. When the method changes, the report separates what changed on your machine from what changed in the method. When the detection rules or the knowledge base change, it says the score is not comparable with the previous one. When the agents evaluated change, or the number of projects drops by more than 10%, it says the two runs are not comparable.
The score is for comparing yourself with yourself, not with anyone else.
Hiding things doesn't buy a better score
- Make a source unreadable: you get no score, not a better one.
- Remove more than 10% of your projects from the configuration: the report marks the comparison with the previous run as not comparable.
- Uninstall an agent: it drops out of the report and the comparison with the previous run is marked not comparable.
- Actually remove a credential from disk: its finding disappears and its weight comes off the score.
What it does not measure
- agents RosmarOps doesn't evaluate yet;
- what an agent does while it runs, since it only reads configuration at rest;
- what an MCP tool does internally;
- the Windows credential store.
What a 100 means
A 100 means: no exposure found in what was read. It never means secure, and it never means protected.