Skip to main content
Field note · Agent security · August 29, 2026

AI defenders need action authority, not just credentials.

Cyber-capable AI can investigate and respond at machine speed. Before it disables an identity, isolates a host, or changes a network rule, the customer still needs one answer: is this exact action inside the authority we gave it?

OpenAI's collective cyber-defense letter calls for more capable AI in defenders' hands, stronger least privilege, accountable agent identities, authorized testing, and verified fixes. That direction is important. It also creates a control problem after the model recommends a response and before a real system changes.

A security product may correctly detect a compromised service identity. Its automation may hold a valid identity-provider credential. Neither fact establishes that the automation may disable this identity, in this tenant, under this incident, at this time.

Detection and authority answer different questions

Detection asks what is happening and what response might help. Authority asks whether this exact response may enter the customer's system of record. A log answers what the operator says happened afterward. These are three different claims.

The authority boundary should sit beside the credential-owning adapter. The AI defender proposes the action without receiving the provider credential. The customer pins the operation, target, limits, evidence, expiry, and exception path. Gate freezes the exact request and permits one provider attempt only when that request fits the mandate.

The crossing
Security product proposes → EMILIA checks exact authority → provider adapter attempts once → action-bound record

The refusal is the product

A credible deployment must demonstrate more than the happy path. If an agent changes the target from one service identity to an entire tenant, the request is wider and provider entry stays closed. If it replays evidence already consumed, it does not receive a second attempt. If a provider times out after entry, the result remains indeterminate and blind retry stays closed until authenticated reconciliation.

Those outcomes are useful to a security vendor because they let the vendor automate a bounded response without asking the customer to treat a standing credential as unlimited permission.

Start with administrative actions, not safety-critical control

In a hospital, the first action should be a privileged IT session or administrative identity, not a clinical decision. In public power, start with remote IT access rather than grid switching. In water, start with a bounded defensive network rule rather than chemical dosing. Independent safety systems and emergency procedures remain independent.

The first buyer should usually be the security vendor, MSSP, SOC platform, or integrator already delivering automated remediation into those environments. EMILIA supplies an authority component inside that deployment. It does not become another EDR, SIEM, SOAR, or critical-infrastructure security suite.

What this does not claim

  • EMILIA does not detect threats, attribute incidents, patch vulnerabilities, or stop exploitation.
  • Gate prevents only on completely mediated covered paths. Alternate credentials and direct provider calls remain outside coverage.
  • Admission does not establish that a response was wise, safe, lawful, or clinically correct.
  • An action receipt does not prove a provider or physical effect without authenticated outcome evidence.

Pressure-test one action

Our opening offer is deliberately small: bring one consequential administrative action, one credential-owning executor, and the current approval path. We will map the boundary, name the bypasses, and demonstrate admission, substitution refusal, replay refusal, and indeterminate handling before anyone relies on it in production.

Run the browser drillScope one protected action
Primary sources