An agent inherits an identity. It does not get its own.
The question people ask is “is AIforce secure?” It is the wrong question. The agent acts under an identity — usually an integration user or a connected-app user — and it inherits that identity’s permissions exactly. Field-level security, object permissions, org-wide defaults, sharing, View All and Modify All all apply unchanged.
The Trust Layer enforces the same model on every surface. It does not add a safety layer on top. So the real question is narrower and much more answerable: what can the identity your agent runs as actually see today? Most admins have never checked.
The UI was doing more security work than anyone admits
For years the screen was the control. A field was technically readable but no layout showed it. An object was Public Read from a decision made in 2019, but nothing in the UI surfaced it. A business rule lived in a screen flow, so every human path went through it.
AIforce removes the UI. An agent reads the field whether or not a layout shows it, and an agent write walks straight past logic that only exists on a screen. Nothing changed about your permissions — what changed is that the UI is no longer hiding them.
Six read-only scans and one score
The kit runs six audits and turns them into a 0–100 exposure score. Three run in the Developer Console Query Editor: the fields exposed to the most profiles and permission sets, objects readable broadly plus every View All and Modify All records grant, and every profile and permission set holding View All Data or Modify All Data with who is assigned.
Three more run in Workbench against the Tooling API: objects whose org-wide default is Public, fields tagged PII or sensitive under Data Classification and whether they are broadly readable, and screen-flow logic an API write bypasses. A one-paste Apex script covers everything Apex can reach and prints the scored report.
What it usually surfaces
An integration user sitting on Modify All Data — the agent just became a god user. Fields readable by every permission set in the org. Objects still set to Public Read from a call made years ago that nobody has revisited. Business rules that live only in a screen flow, which an agent write ignores entirely.
Everything in the kit is SELECT and System.debug only. Nothing is created, changed or deleted. Run it against the profile and permission sets your agent’s running identity will hold — that identity’s access is the agent’s blast radius.
What’s inside
- Six read-only SOQL scanners — three for the Query Editor, three for the Tooling API in Workbench
- A one-paste Apex script that runs the SOQL-reachable checks and prints a scored exposure report
- The fields exposed to the most profiles and permission sets, ranked
- Every profile and permission set holding View All Data or Modify All Data — and who is assigned
- Objects whose org-wide default is still Public, internal and external
- Fields tagged PII, GDPR or sensitive that are also broadly readable
- Screen-flow and UI-only logic that an API or agent write bypasses
- A 0–100 scoring rubric with Low / Moderate / High / Critical bands and the order to fix in