Environment Hardening (EH) - Software Domain

HAIAMM Assessment Questionnaire v3.5

Generated from cells/EH-Software-L*.cell.json. Do not edit by hand. Canonical model: HAIAMM-v3.5-Framing.md · Handbook: HAIAMM-v3.5-Handbook.md.

---

Practice: Environment Hardening (EH) Domain: Software Business Function: Operations Purpose: Publish and apply a hardening baseline for each software AI archetype, so the operating environment enforces the controls rather than documenting them. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

---

Instructions

• Answer from current, implemented practice, not plans or aspirations.
• Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked).
• Levels are derived, never self-assigned. Record evidence and metric values; the level falls out of the scoring below.
• Silence is not a pass. A metric you cannot produce is left blank and counts as not met. Do not estimate.
• Answer progressively. Complete all Level 1 questions before Level 2.

Evidence grade

Record how each answer is known, not only what is claimed (v3.5 framing §6). A level claim is graded at its weakest field.

Grade	Meaning
E0	Asserted by a practitioner, unevidenced
E1	Asserted, with a link to a named artifact
E2	Emitted by a system as telemetry
E3	Machine-attested and independently checkable

---

Scoring Methodology

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + ≥3 outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + <2 outcome metrics meet targets
Not Implemented	0.0	No substantive evidence of practice

Practice maturity level achieved = the highest level where all 3 questions score ≥ 0.67.

---

Maturity Level 1, Foundational

Objective: Publish and apply a hardening baseline for each software AI archetype, so the operating environment enforces the controls rather than documenting them.

Prerequisite cells: SM-Software-L1, PC-Software-L1, SR-Software-L1, SA-Software-L1

Question L1.1: Publish the hardening baseline per archetype

Q1.1: Is a hardening baseline published per software archetype as applicable configuration rather than prose, applied to at least 90% of production assets, and measured against the running environment rather than a checklist?

Evidence Required:

• [ ] Author a hardening baseline per archetype covering single sign-on and least-privilege service identities for AI features, secrets held in a vault rather than in configuration, egress restricted to declared model-provider endpoints, per-feature rate and token limits at the gateway, prompt and tool-call logging enabled at the declared level, and untrusted-content isolation enforced at the boundary
• [ ] Express the baseline as configuration that can be applied and checked rather than as prose, and publish it alongside the reference architecture patterns so that the secure configuration travels with the secure design
• [ ] State for every control whether it is enforcing or advisory, and default to enforcing, because a baseline whose enforcement status is unstated is assumed to be enforcing by everyone reporting on it and is frequently not
• [ ] Where a control genuinely cannot be enforced in the current environment, record it as a known limitation rather than listing it in the baseline as though it were active

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.2: Apply the baseline and measure conformance against the running environment

Q1.2: Are at least 90% of baseline controls in enforcing rather than audit mode, with audit-mode controls recorded as exceptions, and is conformance reported per control rather than as an aggregate that can conceal a missing hard control? For Software, the assessor should be shown the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Apply the baseline to every asset of the archetype and measure conformance from the environment rather than from a checklist
• [ ] Read configuration state, policy enforcement mode and runtime behaviour, and report conformance per control rather than as a single score, because one aggregate number lets a fully conformant set of easy controls conceal a missing hard one
• [ ] Report separately the count of controls running in audit rather than enforcing mode, which is the most common way a baseline is nominally met and practically absent
• [ ] Reconcile monthly and treat any asset with no baseline applied as a finding with an owner rather than as an onboarding backlog item

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.3: Configure consumption limits and govern exceptions

Q1.3: Does every production asset have per-feature token and request limits with a declared at-limit behaviour configured with an explicit declared at-limit behaviour, and does every baseline exception carry an owner, compensating control, approver and expiry?

Evidence Required:

• [ ] Configure per-feature token and request limits with a declared at-limit behaviour as part of the baseline for every asset, expressed relative to per completed task so that the limit bears a defensible relationship to the work the asset actually does
• [ ] Declare the behaviour at the limit explicitly, being degrade, queue or refuse, and never silently continue, because a limit that is exceeded without effect is a reporting artefact rather than a control
• [ ] Operate a baseline exception process: any control not applied requires an owner, a compensating control, an approver and an expiry, reviewed monthly, with expired exceptions treated as findings
• [ ] Exceptions are healthy when visible and corrosive when absorbed into the environment as the new normal

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 1 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Software AI assets with the archetype hardening baseline applied	___	___	≥90% of production assets within 9 months	☐
Baseline controls running in enforcing rather than audit mode	___	___	≥90%, with every audit-mode control recorded as an exception	☐
Assets with consumption limits configured and an explicit at-limit behaviour declared	___	___	100% of production assets	☐
Baseline exceptions carrying an owner, compensating control, approver and expiry	___	___	100%, with none past expiry	☐
Conformance reported per control rather than as a single aggregate score	___	___	100% of baseline controls reported individually	☐

Where each number is read from:

• Software AI assets with the archetype hardening baseline applied — Configuration state reconciled against the baseline definition
• Baseline controls running in enforcing rather than audit mode — Policy enforcement mode audit
• Assets with consumption limits configured and an explicit at-limit behaviour declared — Gateway and platform limit configuration audit; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1
• Baseline exceptions carrying an owner, compensating control, approver and expiry — Exception register
• Conformance reported per control rather than as a single aggregate score — Conformance report structure

Level 1 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Assets with a consumption limit configured and a declared at-limit behaviour	per production asset	___	an environment with no effective ceiling, which leaves denial-of-wallet with no defence at the layer where it would actually be stopped	☐
Configured limit against observed consumption	per completed task	___	limits set so far above real load that they never bind, or so close to it that legitimate work trips them and operations disables the control	☐
Limit breaches where the declared at-limit behaviour did not occur	per limit breach event	___	a limit that is exceeded without effect, which is a reporting artefact rather than a control and is discovered only when it matters	☐

Level 1 Oversight Metrics

"A human approves it" is not a control unless you measure whether they refuse. A metric that cannot fail is not a metric.

Metric	Current	Oversight failure it detects	Met?
Baseline exceptions approved without a compensating control recorded	___	exception approval becoming a formality, where the control is waived and nothing replaces it, which is indistinguishable from not having the control at all	☐
Controls switched from enforcing to audit mode, with the change approved and time-bounded	___	silent downgrade, where a control is moved to audit mode to resolve an operational problem and left there, so the baseline reports as met while enforcing nothing	☐

Level 1 30-second check (E0)

• ☐ Yes ☐ No — Is there a standard secure configuration for your AI systems?
• ☐ Yes ☐ No — Are your AI security controls enforcing, or only logging?
• ☐ Yes ☐ No — Does any AI system have a limit that would actually stop it?

---

Maturity Level 2, Comprehensive

Objective: Calibrate software hardening intensity to asset tier, detect and remediate baseline drift continuously, and make consumption limits tier-proportionate and tested.

Prerequisite cells: EH-Software-L1, SM-Software-L2, IR-Software-L2

Question L2.1: Publish tier-calibrated baselines

Q2.1: Is a baseline variant published per tier with its reasoning and derived automatically from the inventory, rather than one baseline with per-asset exceptions that resolve toward the lighter option? Evidence this in the Software domain against the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Publish a baseline variant per tier rather than one baseline with exceptions
• [ ] Critical adds per-tenant isolation, no standing human access with time-bound elevation, shorter secret rotation intervals, stricter egress allowlisting and full logging
• [ ] Low takes single sign-on and the essential controls
• [ ] Deriving the applicable variant from the inventory tier removes the negotiation that otherwise happens per asset and resolves toward the lighter variant
• [ ] Publish the reasoning alongside the variants so that a team subject to the Critical baseline understands why, because a baseline that arrives without justification is complied with minimally and circumvented where possible
• [ ] Drift in this domain most often appears as logging disabled to reduce volume and a tool allowlist widened during debugging, both reversible and both usually forgotten

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.2: Detect and remediate drift continuously

Q2.2: Are at least 95% of Critical-tier assets under continuous drift detection with a 3 business day detection window, with detections routed into the shared backlog rather than a dashboard, and is standing human access to Critical-tier environments zero? For Software, the assessor should be shown the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Stand up continuous drift detection across the baseline controls for Critical- and High-tier assets, reading configuration state, policy enforcement mode and runtime behaviour, and alerting on change rather than on schedule
• [ ] Publish remediation windows by tier and severity, tighter at Critical, and route detections into the shared issue backlog with tier-appropriate severity rather than into a dashboard
• [ ] Drift is the defining failure of hardening at scale because environments are hardened once and then changed for operational reasons that are individually reasonable: a rule widened for a debugging session, a quota raised under load, an enforcement mode relaxed to unblock a deployment
• [ ] Each is defensible and none is reverted unless something notices
• [ ] Limit exercises in this domain drive a feature to its token ceiling and confirm the declared degrade, queue or refuse behaviour actually occurs rather than the request simply continuing

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.3: Make limits tier-proportionate and exercise them

Q2.3: Has every Critical-tier asset's at-limit behaviour been exercised within 12 months, and do cost-driven changes to limits, logging, retention or enforcement mode require approval as material changes? In Software, ask to see the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Set consumption limits proportionate to tier and to the asset's observed workload, expressed relative to per completed task
• [ ] Exercise the at-limit behaviour at least annually for Critical- and High-tier assets by driving the asset to its limit in a controlled test and confirming that the declared behaviour actually occurs, because a limit whose behaviour has never been observed is an assumption
• [ ] Record the exercise result
• [ ] Treat a cost-driven change to a limit, a logging level, a retention period or an enforcement mode on a Critical-tier asset as a material change requiring approval, since these are precisely the controls that cost pressure erodes and the erosion is invisible on any security dashboard
• [ ] Cost pressure in this domain lands first on prompt and completion logging, which is high-volume and is precisely the corpus detection and investigation depend on

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 2 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Assets running the baseline variant derived from their tier	___	___	100% of Critical and High tier assets	☐
Critical- and High-tier assets under continuous drift detection	___	___	≥95% of Critical, ≥85% of High	☐
Time to detect baseline drift on a Critical-tier control	___	___	≤3 business days at the 90th percentile	☐
Drift remediated within the tier and severity window	___	___	≥90% per tier	☐
Standing human access to Critical-tier AI environments	___	___	0, with time-bound elevation only	☐
Critical- and High-tier assets whose at-limit behaviour was exercised in the last 12 months	___	___	100% of Critical, ≥90% of High	☐

Where each number is read from:

• Assets running the baseline variant derived from their tier — Baseline assignment joined to inventory tier
• Critical- and High-tier assets under continuous drift detection — Drift detection coverage registry
• Time to detect baseline drift on a Critical-tier control — Drift detection event log
• Drift remediated within the tier and severity window — Issue tracker with remediation-window fields
• Standing human access to Critical-tier AI environments — Identity and access review
• Critical- and High-tier assets whose at-limit behaviour was exercised in the last 12 months — Limit exercise log with dates and outcomes

Level 2 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Critical- and High-tier assets whose at-limit behaviour has been exercised and recorded	per Critical or High tier asset	___	a declared limit whose behaviour has never been observed, which is an assumption rather than a control at exactly the tiers that cannot afford one	☐
Limit headroom: configured limit against observed peak consumption, by tier	per completed task	___	limits set without reference to real load, which either never bind or trip on legitimate work and are then disabled by operations	☐
Cost-driven relaxations of limits, logging or retention on Critical-tier assets	per approved change	___	assurance controls eroding under cost pressure with approval, which is the most common and least visible way a hardened environment degrades	☐

Level 2 Oversight Metrics

"A human approves it" is not a control unless you measure whether they refuse. A metric that cannot fail is not a metric.

Metric	Current	Oversight failure it detects	Met?
Time-bound elevations to Critical-tier environments that expired without being reviewed	___	elevation becoming effectively standing access, where a time bound exists on paper and is renewed automatically without anyone assessing whether it is still needed	☐
Drift remediation deferrals at Critical tier, with a named acceptance authority	___	deferral becoming the default response to drift under operational pressure, which converts continuous detection into continuous reporting	☐
Enforcement-mode relaxations approved without an expiry	___	a temporary relaxation becoming permanent because nothing in the approval obliges anyone to revisit it	☐

Level 2 30-second check (E0)

• ☐ Yes ☐ No — Would you know within days if an AI security control was relaxed?
• ☐ Yes ☐ No — Does anyone hold standing admin access to your AI environments?
• ☐ Yes ☐ No — Has anyone tested what happens when an AI system hits its limit?

---

Maturity Level 3, Industry-Leading

Objective: Make software AI environments self-correcting, with baselines applied at provisioning and drift remediated automatically where it is safe to do so.

Prerequisite cells: EH-Software-L2, SA-Software-L3, ML-Software-L2, IM-Software-L2

Question L3.1: Apply baselines at provisioning

Q3.1: Are at least 95% of new assets provisioned already conformant with non-conformance windows at or under one hour, and is provisioning of non-conformant Critical-tier assets blocked? Evidence this in the Software domain against the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Move baseline application to provisioning time so that an asset is conformant from creation rather than hardened afterwards
• [ ] Implement the baseline as infrastructure-as-code modules, admission policies and platform defaults, so the conformant configuration is the default path and a non-conformant asset requires deliberate effort to create
• [ ] Block provisioning of Critical-tier assets that would not meet baseline
• [ ] Measure the time an asset spends non-conformant after creation and drive it to zero, since that window is the one period in an asset's life when it is both unhardened and unmonitored, and it is the window most exploitation of new infrastructure actually uses
• [ ] Provisioning-time conformance in this domain means the scaffold that creates an AI feature also creates its logging, limits and tool allowlist, so an unhardened feature is harder to build than a hardened one

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.2: Automate remediation within enumerated bounds

Q3.2: Are the drift classes eligible for automatic remediation enumerated explicitly with everything else alerting to a human, and is every automated action logged with change, reversion and reason and reviewable rather than silent? For Software, the assessor should be shown the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Enumerate explicitly the drift classes that may be remediated automatically, being those where the correct state is unambiguous and reversion carries no operational risk, such as re-enabling logging, restoring an enforcement mode, or closing an egress rule not in the allowlist
• [ ] Everything outside that list alerts to a human
• [ ] Log every automated action with what changed, what it was reverted to and why, and make the log reviewable, because self-correction that is silent can mask a genuine operational need indefinitely and the team whose change was reverted will simply make it again
• [ ] Track repeated remediation of the same control on the same asset as a signal that the baseline is wrong or the operational need is real, and route it to review rather than continuing to revert
• [ ] Safe automatic remediation in this domain covers re-enabling prompt and tool-call logging and restoring a tool allowlist, both unambiguous and both commonly disabled during debugging

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.3: Govern adaptive limits and publish the automation boundary

Q3.3: Is repeated automatic remediation of the same control treated as a signal routed to baseline or operational review, and do adaptive limits operate within a governed hard ceiling requiring human approval to cross? In Software, ask to see the applied hardening baseline for one AI feature, with its enforcement mode.

Evidence Required:

• [ ] Allow consumption limits to adapt to observed workload within governed bounds, so that a limit tracks the asset's real demand rather than remaining static and becoming either irrelevant or obstructive
• [ ] Set a hard ceiling that adaptation cannot cross without human approval, because an adaptive limit with no ceiling accommodates an attack as readily as it accommodates growth, and that is precisely the failure mode denial-of-wallet exploits
• [ ] Express bounds relative to per completed task
• [ ] Publish the list of controls that cannot be automatically applied or remediated and review it quarterly for reduction, so that the boundary of the automation is known rather than assumed to be complete
• [ ] Adaptive limits in this domain track tokens per completed task, so a feature whose workload genuinely grew is accommodated while one that started looping is not

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

Answer:

• ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets)
• ☐ Implemented (Evidence complete + 2 metrics meet targets)
• ☐ Partial (Evidence partially complete + <2 metrics meet targets)
• ☐ Not Implemented (No evidence)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 3 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Assets provisioned already conformant to their tier baseline	___	___	≥95% of new assets	☐
Time an asset spends non-conformant after creation	___	___	≤1 hour at the 90th percentile	☐
Enumerated safe drift classes remediated automatically	___	___	≥80% of drift events in the enumerated classes	☐
Automated remediations logged with change, reversion and reason, and reviewable	___	___	100%	☐
Repeated automatic remediation of the same control on the same asset	___	___	tracked, with any control remediated more than three times routed to review	☐
Adaptive limits operating within a governed hard ceiling	___	___	100% of adaptive limits carry a ceiling requiring human approval to cross	☐

Where each number is read from:

• Assets provisioned already conformant to their tier baseline — Provisioning telemetry joined to conformance scan
• Time an asset spends non-conformant after creation — Provisioning and conformance timestamps
• Enumerated safe drift classes remediated automatically — Automated remediation log
• Automated remediations logged with change, reversion and reason, and reviewable — Remediation audit log
• Repeated automatic remediation of the same control on the same asset — Remediation log aggregated by control and asset
• Adaptive limits operating within a governed hard ceiling — Limit configuration audit

Level 3 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Adaptive limits operating within a governed hard ceiling	per asset with an adaptive limit	___	an adaptive limit with no ceiling, which accommodates an attack exactly as readily as it accommodates growth and is the specific failure denial-of-wallet exploits	☐
Cumulative ceiling increase over the trailing year, per asset	per completed task	___	ceiling creep through individually justified increases, where the cumulative effect is an unbounded limit that nobody decided to create	☐
Drift events on consumption-limit configuration, and time spent drifted	per limit configuration drift event	___	limits silently relaxed and left relaxed, which removes the one control that denial-of-wallet actually encounters	☐

Level 3 Oversight Metrics

"A human approves it" is not a control unless you measure whether they refuse. A metric that cannot fail is not a metric.

Metric	Current	Oversight failure it detects	Met?
Automated remediations reverted by a human within 24 hours	___	automation acting against a genuine operational need, which indicates the enumerated safe class was wrongly scoped and is invisible unless reversions are tracked	☐
Adaptive limit ceiling increases approved, with the approver and justification recorded	___	ceiling creep, where each individual increase is justified and the cumulative effect is an unbounded limit nobody decided to create	☐
Alerts for non-automatable drift acknowledged but not remediated within the tier window	___	alert fatigue on the drift classes that specifically require human judgment, which are the ones automation deliberately left to people	☐

Level 3 30-second check (E0)

• ☐ Yes ☐ No — Is a new AI asset hardened before it exists, or afterwards?
• ☐ Yes ☐ No — Does your environment fix a disabled control on its own?
• ☐ Yes ☐ No — Can an adaptive limit grow without anyone approving it?

---

Summary Scorecard

Level	Q1	Q2	Q3	Level score	Weakest evidence grade	Achieved?
L1	___	___	___	___	___	☐
L2	___	___	___	___	___	☐
L3	___	___	___	___	___	☐

Environment Hardening (EH) maturity in the Software domain: ____________

---

Document Version: HAIAMM v3.5 (generated)