DELXSECURITY

Control baseline / defensive assurance

AI agent security controls: a risk-based baseline.

The Delx Security baseline turns agentic risk into 20 observable outcomes across ownership, authority, tools, context, secrets, evidence and recovery. It is a risk-based starting point — not a universal checklist, certification or guarantee.

Direct answer

Start with authority and evidence

An AI agent security control is useful when it states an outcome an owner can observe and a reviewer can verify. Begin with who owns the system, who can act, what tools and destinations it can reach, what context can become durable policy, and how an operator stops and recovers it. Then select only the controls that break the credible attack paths for the system's impact and maximum authority.

Twenty control outcomes

GOV-01 · GOV-02

Governance

Outcome: A named owner and explicit mission, prohibited actions and risk tolerance.

Evidence: Role record, approval trail, policy and use-case boundary.

AST-01 · IAM-01–03

Inventory and authority

Outcome: Models, agents, tools, data, memory and suppliers are inventoried; identities are attributable, narrow and revocable, including delegated chains.

Evidence: Architecture, asset catalog, auth logs, policies, denial tests and delegation traces.

ACT-01–03 · CTX-01–03

Actions and context

Outcome: Typed tool contracts, action-time approval and allowlisted egress protect provenance, memory integrity and policy from untrusted context.

Evidence: Schemas, negative tests, approval event, egress policy, retrieval trace, rollback proof and adversarial test record.

SEC-01 · APP-01 · SUP-01

Secrets, application and supply chain

Outcome: Secrets are scoped and redacted; application controls are selected deliberately; code, models, prompts, skills and dependencies have provenance.

Evidence: Vault and log inspection, requirement matrix, tests, lockfile, attestations and review record.

OBS-01 · OBS-02

Audit and detection

Outcome: Decisions and side effects are attributable, with actionable signals for abuse, drift and anomalous authority.

Evidence: Immutable event trail, alert exercise and response log.

RES-01 · RES-02 · VER-01

Stop, recover and verify

Outcome: Operators can pause or revoke safely, recover state, evidence and authority consistently, and recheck critical controls after change.

Evidence: Kill-switch and restore exercises, runbook, CI gate and production probe.

How to select controls

  1. Classify the system's impact and maximum authority, including delegated and emergency paths.
  2. Select the outcomes that break a credible attack path or make a high-consequence failure observable.
  3. State which controls are not selected and why; an exclusion is a decision, not a blank cell.
  4. Name the evidence that proves each outcome and the owner who can produce it.
  5. Verify live behavior where the truth is outside code, configuration or a policy document.

Priority starting set

01 / Authority

Identity and delegation

Make every actor attributable, least-privileged and independently revocable, including hand-offs between agents and services.

02 / Actions

Tools, approval and egress

Type inputs, expose side effects, require approval at action time for high-impact effects and constrain destinations.

03 / Context

Provenance and memory

Keep retrieved content and instructions distinguishable; authenticate durable writes and resist context that tries to redefine authority.

04 / Resilience

Evidence, stop and recovery

Record decisions and side effects, detect drift, prove a pause and revocation path, and rehearse consistent restoration.

Framework alignment without certification

The baseline uses the public vocabulary of NIST CSF 2.0, NIST AI RMF, NIST SSDF 1.1, OWASP Top 10 for Agentic Applications, OWASP ASVS 5.0, MITRE ATLAS and CISA Secure by Design. The mapping helps teams find evidence; it does not copy a framework into a score or claim certification.

Runtime behavior outranks declared configuration

A policy, diagram or static setting is intent. Assurance requires a trace, test, exercise or other evidence that the deployed system behaves within the stated boundary.

Safety boundaries

  • Defensive work only, on systems owned by the requester or explicitly authorized in writing.
  • Active testing waits for written Rules of Engagement with exact assets, techniques, timing and stop rules.
  • No unbounded scanning, denial of service, destructive testing, persistence, social engineering or third-party targeting by default.
  • The baseline is not a certification, legal-compliance opinion or guarantee that future releases remain safe.

Further reading

Direct answers

Q&A

What are AI agent security controls?

They are observable security outcomes for an agentic system: accountable ownership, attributable identity, bounded authority, safe tool and egress behavior, trustworthy context and memory, protected secrets, evidence, recovery and continuous verification.

Q&A

How many controls are in the Delx Security baseline?

Version 1.0 has 20 control outcomes grouped across governance, inventory and authority, actions and context, secrets and supply chain, audit and detection, and stop, recovery and verification. It is a risk-based starting point, not a universal checklist.

Q&A

Is this a NIST or OWASP certification?

No. Delx Security uses NIST, OWASP, MITRE ATLAS and CISA publications as a shared vocabulary for evidence and threat paths. The baseline does not certify a system, prove legal compliance or guarantee future security.

Q&A

Which AI agent controls should a team implement first?

Start with ownership and scope, attributable least-privilege identity, delegated authority, typed tool contracts, action-time approval, constrained egress, secret handling, attributable audit, a stop path and recovery. Choose the smallest set that breaks the credible attack paths for the system's impact and authority.

Q&A

How does a control baseline relate to threat modeling?

Threat modeling maps credible abuse paths and consequences. The baseline names minimum outcomes and evidence to test along those paths. A bounded security review then verifies authorized behavior and records limitations instead of treating a completed checklist as proof.