ATI Methodology · v1.0-beta

Authority requires assurance.

ATI evaluates the relationship between the authority an intelligent system holds and the strength of the assurance around it. Every rule that produces an ATI result is published on this page.

Foundation

Two quantities, judged against each other

ATI is not primarily trying to determine whether an AI system is safe. It asks a narrower question that can be answered and defended: given the controls and evidence available, what degree of authority is justified?

Authority Exposure

What the system can do, and what happens if it is wrong.

Action class, blast radius, impact of failure, data sensitivity. Exposure describes stakes, not quality.

Assurance Strength

What constrains the system, and what proves the constraints hold.

Identity, enforcement, boundaries and evidence, measured as Trust Readiness and Evidence Confidence.

The instrument

One sentence, four clauses

ATI is grounded in The Trust Architect’s Handbook, whose working instrument is a single sentence that any trust claim can be tested against:

An identified subject, holding bounded authority, took a checked action, on a record that survives a skeptic.

Clause	The question	ATI domains
An identified subject	Who or what acted, provably?	Identity
holding bounded authority	On whose behalf, within what limits?	Authority · Identity (delegation)
took a checked action	Was this action permitted, decided before it happened?	Enforcement · Boundaries
on a record that survives a skeptic	Can we reconstruct it, attributed and unaltered?	Evidence

Every ATI finding is a broken clause, stated in terms an engineer can fix and a board can understand.

Five domains

What ATI evaluates

Domain 01

Authority

What can the system actually do?

The actions available to the system, the consequences if they go wrong, and whether consequential actions pass through an approval that is bound to the specific action.

Evaluates

Read authority
Draft authority
External communications
Write authority
Transactions
Infrastructure changes
Consequential decisions
Financial authority
Approval requirements
Blast radius

Domain 02

Identity

Under whose authority is the system acting?

Whether actions are attributable to a distinct, scoped, non-human identity, and whether delegated authority narrows as it moves between users, agents and tools.

Evaluates

Attributable identity
Non-human identity
Workload identity
Credential scope
Credential lifetime
Shared credentials
Human credential impersonation
Delegated authority
Agent-to-agent delegation
Least privilege

Domain 03

Enforcement

What actually prevents the system from exceeding its authority?

The difference between soft controls that guide behavior and deterministic controls that execute outside the model, on every action, and fail closed.

Evaluates

API enforcement
Authorization policies
Scoped permissions
Approval gates
Transaction limits
Policy engines
Runtime restrictions
Isolation
Revocation mechanisms

Domain 04

Boundaries

Where does the system's authority stop?

The edges of what the system can reach: data, tools, destinations, environments, tenants and downstream dependencies.

Evaluates

Sensitive data boundaries
Environment boundaries
Tenant isolation
Tool allowlists
Destination restrictions
Delegation limits
External communication boundaries
Financial limits
Privilege escalation
Dynamic tool loading
Downstream agents
Supply-chain dependencies

Domain 05

Evidence

Can the organization's trust claims actually be demonstrated?

Whether claims about the other four domains are backed by attributable records, tests, dated artifacts and an accountable owner.

Evaluates

Logging
Action attribution
Tool-call records
Policy decisions
Approval records
Testing
Red-team / adversarial testing
Revocation testing
Rollback testing
Configuration evidence
Incident reconstruction
Ownership
Dated evidence

Domain 3 · Enforcement

Soft controls and deterministic controls

Soft controls · guide behavior

Prompts
System instructions
Policies
Documentation

Deterministic controls · bound authority

API enforcement
Authorization policies
Scoped permissions
Approval gates
Transaction limits
Policy engines
Runtime restrictions
Isolation
Revocation mechanisms

How ATI works

ATI Screen, step by step

System context. Stage, impact of failure and data sensitivity. These set exposure; they do not score readiness.
Twenty domain questions, four per domain. Each answer is mapped to published points and to named facts (for example, “approval is enforced”).
Scoring. Domain scores, Trust Readiness and ceilings are computed from the points.
Exposure and confidence. Computed separately from readiness, by the rules below.
Gating. Explicit conditions on the facts limit the authority recommendation. Triggered gates are always shown.
Recommendation. The recommended authority boundary, up to 5 priority gaps, and the evidence that would increase assurance.

The engine is deterministic: the same answers always produce the same result. It runs in your browser; answers are not transmitted.

Scoring

Trust Readiness, in four rules

Each scored answer carries published points: 100 strong · 75 substantial · 55 partial · 15 weak · 0 absent or unknown.
A domain score is the unweighted mean of that domain’s scored questions. Two Authority questions (action class and blast radius) describe exposure and are not scored. Questions that only apply to systems that can act (approval, action limits) are excluded for read- or draft-only systems.
Raw readiness is the unweighted mean of the five domain scores. Each domain counts equally.
Trust Readiness is raw readiness limited by the lowest applicable ceiling.

Ceilings

Condition	Ceiling
Strongest evidence reported is “Assertion”	40
Strongest evidence reported is “Documented”	50
Strongest evidence reported is “Implemented”	70
Strongest evidence reported is “Tested”	90
Evidence basis unknown	35
System is an idea or design	35
System stage unknown	40
Authority exposure undetermined	40

Readiness bands

0–39 Unproven · 40–69 Developing · 70–100 Provisionally supported. Domain bands: Strong 75–100 · Partial 40–74 · Weak 0–39.

Authority Exposure

The highest level among action class, blast radius, impact of failure and data sensitivity (Low, Moderate, High). Exposure is Severe when the system can move money, change production systems or make decisions about people and the impact of failure is serious. It is Undetermined when action class, impact or data sensitivity is unknown. Exposure never lowers readiness: a high score does not reduce the consequences of failure.

Evidence Confidence

High: strongest evidence is Tested or Independently Verified, reconstruction and testing answers are the strongest option, and at most one answer is unknown.
Moderate: strongest evidence is at least Implemented, the Evidence domain scores 50 or more, and at most three answers are unknown.
Low: otherwise. In ATI Screen, confidence is always based on self-reported evidence.

Priority gaps

Any scored answer below 100 produces a candidate finding. Candidates are ranked by gap size × question weight (1–3), multiplied by an exposure factor for exposure-sensitive questions (Low 1 · Moderate 1.25 · High 1.5 · Severe 1.75 · Undetermined 1.5). Findings linked to a triggered gate rank first. At most 5 are shown.

Gating

Conditions that override a high score

A system should not receive an elevated authority recommendation merely because its aggregate score is high. Gates are explicit rules on named facts. They cap the authority recommendation, never the score, and every triggered gate is shown to the user. Where the system’s action authority is unknown, ATI conservatively treats it as able to write.

Gate	Rule	Caps at
Exposure gate	If what the system can do, the impact of failure, or the data it can reach is unknown, no authority above Draft is recommended.	Draft
Consistency gate	If write authority is reported while another answer says no consequential actions are possible, no authority above Draft is recommended until the conflict is resolved.	Draft
Approval gate	Write authority without enforced, action-bound human approval cannot be recommended for autonomous execution.	Act with Approval
Identity gate	Write authority exercised under an identity that cannot be attributed to the system cannot be recommended for autonomous execution.	Act with Approval
Least-privilege gate	Write authority with materially overbroad or unknown permissions cannot be recommended for autonomous execution.	Act with Approval
Enforcement gate	Where the only boundary on write authority is prompts, instructions or policy text, autonomous execution cannot be recommended.	Act with Approval
Delegation gate	Where delegated authority does not narrow, or cannot be traced to its origin, autonomous execution cannot be recommended.	Act with Approval
Revocation gate	Autonomous execution cannot be recommended until revocation of the system's authority has been tested.	Act with Approval
Reconstruction gate	Autonomous execution cannot be recommended when consequential actions cannot be reconstructed from records.	Act with Approval
Independent review gate	High-impact uses cannot be recommended for Expanded Autonomy without independently verified evidence.	Bounded Autonomy

Authority levels

Five authority boundaries

Level 0
Observe
The system can retrieve and read information.
Level 1
Draft
The system can generate recommendations or proposed actions. A person executes them.
Level 2
Act with Approval
The system may prepare consequential actions, but authenticated human authorization is required before execution.
Level 3
Bounded Autonomy
The system may execute defined actions autonomously within deterministic constraints.
Level 4
Expanded Autonomy
Reserved for systems with strong controls, evidence, monitoring, recovery, and clearly bounded consequences.

How the recommendation is formed

The recommended boundary is the lowest of three things:

The authority justified by readiness and confidence: Expanded Autonomy requires readiness ≥ 85 and High confidence; Bounded Autonomy requires ≥ 70 and at least Moderate confidence; Act with Approval requires ≥ 45; otherwise Draft. ATI Screen does not recommend below Draft on self-reported answers.
The authority the system currently holds, as reported. ATI does not recommend expanding authority from a self-assessment.
The cap of every triggered gate.

When the current authority is higher than the recommendation, ATI reports that authority exceeds assurance. Current authority is derived from your answers: read-only is Observe; draft-only is Draft; write authority with enforced, action-bound approval is Act with Approval; without approval but with enforced limits, Bounded Autonomy; with neither, Expanded Autonomy.

Evidence maturity

From assertion to independent verification

Evidence is what survives someone who assumes you are wrong. ATI tracks the strongest evidence behind a result and limits what the result can claim accordingly.

01
Assertion
Someone states that the control exists.
Readiness ceiling: 40
02
Documented
A design, policy or procedure describes the control.
Readiness ceiling: 50
03
Implemented
Current configurations or records show the control is in place.
Readiness ceiling: 70
04
Tested
Dated test results show the control operates, including attempts to bypass it.
Readiness ceiling: 90
05
Independently Verified
A qualified party outside the delivery team examined the evidence.
Readiness ceiling: 100

Inspectable

The complete question set

Every question, answer and point value in ATI Screen v1.0-beta. “Exposure” marks answers that set stakes rather than score readiness.

System context (3)

What stage is the system in?
ctx.stage · v1.0
- An idea or designExposure
- A prototype or pilotExposure
- In productionExposure
- UnknownExposure
What happens if the system gets it wrong?
ctx.impact · v1.0
- Minor inconvenience that is easily correctedExposure
- Material harm to the business or its customersExposure
- Financial, legal, health, safety, or essential-service harmExposure
- UnknownExposure
What is the most sensitive information the system can access?
ctx.data · v1.0
- Public or synthetic information onlyExposure
- Internal business informationExposure
- Personal, confidential or regulated data, or secretsExposure
- UnknownExposure

Authority — What can the system actually do? (4)

What is the most consequential action the system is technically able to take?
auth.actions · v1.0
- Read, retrieve or analyze information onlyExposure
- Draft or recommend; a person sends or executesExposure
- Change internal records or workflowsExposure
- Communicate externally on the organization's behalfExposure
- Move money, change production systems, or make decisions about peopleExposure
- UnknownExposure
If the system acted wrongly at machine speed, how far could the damage spread before someone intervened?
auth.blast · v1.0
- One record, user or conversation; easily reversedExposure
- A limited set of records, customers or funds; mostly reversibleExposure
- Many customers, systems or funds; difficult or impossible to reverseExposure
- UnknownExposure
What must happen before a consequential action executes?
auth.approval · v1.0 · applies only when the system can act
- Nothing: the system cannot take consequential actions100
- Authenticated human approval, enforced by the system and bound to the specific action100
- Enforced approval, but not tied to the exact action, target or amount55
- Approval is informal, prompt-based, or happens after the action15
- No approval is required0
- Unknown0
Has anyone explicitly granted the system its authority?
auth.grant · v1.0
- Yes: a named approver, a defined scope, and an expiry or review date100
- A named approver and scope, but no expiry or review date55
- Not explicitly: it inherited whatever access it was deployed with15
- Unknown0

Identity — Under whose authority is the system acting? (4)

When the system acts, what identity does it act as?
id.identity · v1.0
- Its own non-human identity, distinguishable per instance or run100
- Its own dedicated identity, shared by all its instances75
- A service account shared with other applications or systems15
- A person's credentials, or a shared API key0
- Unknown0
How closely do the system's permissions match what its tasks require?
id.privilege · v1.0
- Scoped to its tasks and reviewed since the last change100
- Scoped when set up, but not reviewed since55
- Broader than needed (for example admin, wildcard or inherited permissions)15
- Unknown0
How does the system obtain the credentials it uses to reach other systems?
id.credentials · v1.0
- Short-lived credentials issued on demand to its identity100
- Stored in a secrets manager and rotated on a schedule55
- Long-lived keys or tokens in configuration, environment variables or code15
- Credentials can appear in prompts, memory, or tool output0
- Unknown0
When the system acts for a user or hands work to other agents or tools, what happens to authority?
id.delegation · v1.0
- No delegation: it uses a fixed set of approved tools under its own identity100
- Each hop carries the originating user and narrower, enforced limits100
- The originating user is recorded, but authority does not narrow40
- Full authority passes downstream, or the originating user is lost0
- Unknown0

Enforcement — What actually prevents the system from exceeding its authority? (4)

What primarily prevents the system from taking actions outside its intended scope?
enf.mechanism · v1.0
- Deterministic checks outside the model, on every action100
- Deterministic checks for some actions; prompts or instructions for others55
- Prompts, system instructions, or written policy only15
- Nothing specific0
- Unknown0
Does every consequential action pass through the enforcement point, and what happens if the check fails?
enf.path · v1.0
- One path, and a failed or unavailable check blocks the action (tested)100
- One path, but failure behavior is untested or allows the action55
- Other paths to consequential systems exist15
- There is no enforcement point0
- Unknown0
Are hard limits enforced on consequential actions?
enf.limits · v1.0 · applies only when the system can act
- Not applicable: the system cannot take consequential actions100
- Yes, enforced per action and in aggregate over time100
- Enforced per action only55
- Limits are documented but not technically enforced15
- No limits0
- Unknown0
Can you stop the system and remove its authority quickly?
enf.revocation · v1.0
- Yes: tested revocation of credentials, downstream sessions and queued work100
- A stop and revoke mechanism exists but has not been tested55
- Only by shutting down the application or interface15
- No mechanism0
- Unknown0

Boundaries — Where does the system's authority stop? (4)

How is the system's access to data bounded?
bnd.data · v1.0
- Enforced per task, user or tenant: it can reach only what the current request needs100
- Enforced at a coarse level (whole databases, drives or systems)55
- Broad access, limited only by instructions15
- Unknown0
Which tools, plugins, or MCP servers can the system use?
bnd.tools · v1.0
- It does not use tools100
- A fixed allowlist, reviewed, with versions or sources pinned100
- An allowlist that can change without review55
- It can discover or load tools, or connect to servers, at runtime0
- Unknown0
Where can the system send data, messages, or requests?
bnd.egress · v1.0
- Nowhere outside its own environment100
- Only to allowlisted destinations, technically enforced100
- Any destination, but a person reviews outbound content first55
- Any destination, without enforced restriction0
- Unknown0
If the system misbehaves or is compromised, what contains it?
bnd.isolation · v1.0
- An isolated runtime and network, reaching production only through enforced interfaces100
- Partial isolation (for example separate environment, shared network)55
- It runs alongside production systems with broad network access15
- Unknown0

Evidence — Can the organization's trust claims actually be demonstrated? (4)

Could you reconstruct a past action from records alone?
evd.reconstruct · v1.0
- Yes: attributable, complete records protected from alteration100
- Partly: some records exist, but the chain is incomplete55
- Logging is planned only15
- No0
- Unknown0
Have the system's boundaries and recovery been tested?
evd.testing · v1.0
- Repeatable adversarial and recovery tests, with failures remediated100
- Some testing, with gaps or unresolved failures55
- Testing is planned only15
- No testing0
- Unknown0
What is the strongest evidence behind your answers in this assessment?
evd.maturity · v1.0
- Independently verified: a qualified outside party examined it100
- Tested: dated test results show the controls operate75
- Implemented: current configurations and records exist55
- Documented: designs, policies or procedures15
- Assertion: our understanding of how it works0
- Unknown0
Is a named person accountable for the system's authority, and is the evidence kept current?
evd.ownership · v1.0
- Yes: a named owner, and evidence is re-reviewed after changes100
- A named owner, but evidence is not refreshed after changes55
- No named owner0
- Unknown0

Framework mappings

Supporting mappings, not a wrapper

ATI’s organizing question is its own: does the assurance surrounding this system justify the authority it has been granted? Established sources such as the NIST AI Risk Management Framework and OWASP guidance for LLM and agentic applications are useful supporting references.

ATI v1.0-beta publishes no framework mappings. ATI adds a mapping only after confirming the exact identifier and title against the current official source, confirming the mapping is substantively defensible, and recording the source version. Mappings are ATI's, not claims by the source framework.

Limitations

What an ATI result is not

ATI scores are not probabilities of safety.
ATI scores are not certifications.
ATI results are not legal advice.
ATI results are not regulatory approvals.
ATI results are not deployment authorization.
ATI results are not guarantees of system behavior.

ATI Screen results are provisional and self-reported. Evidence is not independently verified. Weights, thresholds and gates are published heuristics that have not yet been empirically validated. High-impact uses require qualified review regardless of result.

ATI Screen samples the action layer of trust architecture. It does not evaluate model-layer security, model evaluation methodology or privacy engineering as disciplines in their own right. Sufficiency remains a judgment made by a named, accountable person.

Version

ATI is auditable too

Methodology version	1.0-beta
Engine version	1.0.0
Export schema	1.0 (JSON Schema)

Every change to questions, scoring, gates, authority levels, evidence maturity or mappings is versioned. See the methodology changelog.

Assess Your System →View changelog