004 - Policy One - Agent eligibility is policy-defined

Chapters:

Get Smart does not ask whether every machine can run an agent. It asks whether this machine, for this role, under this policy, should be assessed, trusted, remediated, protected, or excluded.

The core idea:

Agent eligibility is not universal. It is determined by machine type, role, ownership, risk, and permitted remediation path.

Agent eligibility is policy-defined

Agent Eligibility Policy

Classification	Meaning
`agent_allowed`	Agent may be installed if useful or required
`agent_recommended`	Agent is useful, but not mandatory
`agent_required`	Machine cannot receive full readiness approval without it
`agent_restricted`	Agent may be installed only with approval or maintenance window
`agent_prohibited`	Agent must not be installed under current policy
`agent_unknown`	More evidence required before deciding

Machine types and default agent posture

Machine type	Default agent posture	Why
Legacy servers	`agent_restricted`	old OS, fragile dependencies, unknown side effects
Medical/industrial systems	`agent_prohibited` or `agent_restricted`	certified configuration, vendor restrictions
OT/ICS machines	`agent_prohibited` or `agent_restricted`	uptime and safety concerns
Air-gapped/semi-isolated systems	`agent_restricted`	restricted connectivity
Vendor appliances	`agent_prohibited`	support contracts may forbid changes
High-performance systems	`agent_restricted`	agents may affect timing/performance
Regulated systems	`agent_restricted`	extra software changes audit scope
Short-lived cloud systems	`agent_allowed` but often `agent_not_required`	installing agents may be wasteful
Client-owned demo/sandbox machines	`agent_restricted`	ownership and permission unclear
Build runners	`agent_restricted`	agent conflicts can contaminate builds
Standard managed workstation	`agent_allowed`	expected management surface
Standard managed server	`agent_allowed`	expected management surface

That gives us the practical policy line:

Some machines can run AACM agents. Others must be protected from unnecessary change.

Excellent. Keep that.

Better policy wording

I would state it like this:

Agent installation is a remediation option, not a default assumption.

And:

Systems that are fragile, regulated, vendor-controlled, safety-sensitive, or short-lived may require agentless assessment, manual review, compensating controls, or exclusion from automated remediation.

That is mature. Less “we hate agents,” more “we understand operational risk.”

How this fits Get Smart Machine Readiness

A readiness policy should include an agent posture section.

Example:

policy_id: machine-readiness-v0.1

agent_policy:
  default: agent_unknown

  machine_type_rules:
    - machine_type: legacy_server
      agent_posture: agent_restricted
      reason: legacy_fragility

    - machine_type: medical_industrial
      agent_posture: agent_prohibited
      reason: certified_configuration_or_vendor_restriction

    - machine_type: ot_ics
      agent_posture: agent_prohibited
      reason: uptime_or_safety_risk

    - machine_type: vendor_appliance
      agent_posture: agent_prohibited
      reason: support_contract_restriction

    - machine_type: build_runner
      agent_posture: agent_restricted
      reason: build_contamination_risk

    - machine_type: standard_managed_server
      agent_posture: agent_allowed
      reason: expected_management_surface

Then the assessment output can say:

{
  "machine_id": "gsmr-lab-001",
  "machine_type": "legacy_server",
  "readiness_status": "review_required",
  "agent_posture": "agent_restricted",
  "agent_required": false,
  "recommendation": "Use agentless assessment or owner-approved maintenance window.",
  "reason": "legacy_fragility"
}

Important distinction

There are three separate decisions:

Decision	Question
Can we assess it?	Are we allowed to collect evidence?
Can we trust it?	Does the evidence satisfy policy?
Can we change it?	Is remediation or agent install permitted?

Do not let those collapse into one blob.

A machine might be:

assessable but not changeable
trusted for limited use but not production
eligible for manual remediation but not agent remediation
unscannable but documented as an exception
healthy but not approved because ownership is unclear

That is the Get Smart advantage: classification instead of fake binary certainty.

Add this to the doctrine

Here’s the clean version for your notes:

Agent eligibility is policy-defined

Get Smart Machine Readiness does not assume that every system should run an agent.

Agent installation is treated as a remediation option, not a default requirement. Some systems can safely run agents. Others must be protected from unnecessary change because they are fragile, regulated, vendor-managed, safety-sensitive, short-lived, or owned by another party.

A readiness policy should define whether an agent is allowed, recommended, required, restricted, prohibited, or unknown for each machine type and requested role.

Core rule:

Assess first.
Classify risk.
Install only when policy allows and evidence justifies it.

This also helps with recommendations

Recommendations can include value and risk:

Recommendation	Value	Change risk	Result
Install AACM agent	High	Low	recommended
Install AACM agent on legacy server	Medium	High	restricted / review required
Use OSQuery read-only checks	High	Low	recommended
Patch manually during maintenance window	High	Medium	recommended
Ignore hostname inconsistency	Low	Low	optional
Add owner record	High	Low	required
Agent on vendor appliance	Low/Unknown	High	prohibited unless vendor approves

That gives you the practical report shape:

“Here is what we recommend. Here is the value. Here is the risk. Here is whether you can ignore it. Here is whether an agent is appropriate.”

The best sentence

Use this one:

Get Smart does not ask whether every machine can run an agent. It asks whether this machine, for this role, under this policy, should be assessed, trusted, remediated, protected, or excluded.

That is the big-market sentence.

agents