A tool that maps what your AI agents can reach has to connect to your cloud, your code platform and your identity provider. That is a lot of trust to ask for, and it raises a fair question: what stops that tool from becoming the next problem?
Our answer is a design rule. nerl0 connects read-only, and it never needs write access to do its job.
In this piece, we will cover:
- Why a security tool should not hold write access
- What nerl0 reads, and what it does not
- What read-only means for the way you fix things
- How long what it collects is kept
Why a security tool should not hold write access
Every credential you give a tool is one more door. A tool that can change your systems is a tool whose compromise can change your systems. The more access it holds, the more it is worth attacking.
It would be ironic for a product about reducing what agents can reach to ask for a broad set of keys. So the rule is simple: if nerl0 does not need to change something to show you the problem, it does not get to.
What nerl0 reads, and what it does not
nerl0 connects to each platform through its own interfaces and reads configuration and permission data. It builds a map of authority. It does not copy your data.
| nerl0 reads | nerl0 does not read |
|---|---|
| Roles, keys and grants | The contents of your data stores |
| Paths between identities and stores | Documents, messages and code files |
| Which agents and MCP servers exist, and who answers for them | Secret values behind a key |
| What changed since the last scan |
The map shows that a role can read a secret. It does not need the secret itself to say so.
What read-only means for how you fix things
Because nerl0 cannot change anything, every fix is yours to apply. The product recommends a breakpoint, for example removing a role's read access to a secret. You make the change in the platform, with your own review and your own approval process.
That is slower than a button that fixes it for you, and it is deliberate. The change goes through your process, is visible in your audit trail, and can be reviewed by the person who owns the system. The next scan then checks whether the route is gone.
Updated 09 NovOHops-automation-agent can write to production crown-jewel prod/payments/stripe-key
Updated 09 NovOHanthropics/claude-code-action in northstar-tech/platform can write to repositories
Open–Assign an owner to the unowned agent
Updated todayMCThe AWS root access key can perform any action on any resource in the account
ClosedMCRotated secret no longer reachable from other accounts
How long what it collects is kept
Observations are kept for 90 days and decision evidence for one year. Workspaces are separated from each other, and access inside a workspace is limited by roles: Owner, Admin, Security Analyst, Auditor and Read only. The Trust page has the details.
Read-only describes what nerl0 can do to your systems. It does not describe what your connected platforms expose to it. Granting a connector access is still a decision that deserves the same review as any other integration.
Summary
A security tool with write access to your systems becomes part of the problem it reports. nerl0 reads configuration and permission data, never the contents of your data stores, and leaves every change to you. The next scan verifies the result.
Sascha writes about what AI agents and non-human identities can reach, and builds nerl0 to keep that visible.