Korea’s planned agent-security checklist should become a deployment gate, not shelfware
KISA says it is revising its AI Security Guide for agentic and physical AI. Until the checklist is published, organisations can still convert the direction into a narrow gate for identity, tools, memory and real-world actions.
What happened
South Korea’s internet security agency told Reuters it is updating its AI Security Guide to address agentic systems and may include common controls for physical AI.
Why it matters
A checklist is useful only when each control has an owner, evidence artifact, failure threshold and stop condition before an agent receives production access.
South Korea’s state-run internet security agency is updating its AI Security Guide for systems that operate with less human supervision. Reuters reported that KISA intends to focus the revision on risks from agentic AI services, provide a management checklist and possibly include common controls for “physical AI” that can interact with machinery and other real-world devices.
The direction is useful; the evidence is still prospective. KISA has not published the revised checklist, a delivery date or test results. Organisations should not claim compliance with a document that does not yet exist. They can, however, use the announcement to ask whether their current launch process is capable of producing the evidence any credible checklist will need.
Gate the action path, not only the model
Agent security is a system property. A model can be well evaluated and still sit inside a weak chain of credentials, connectors, memory stores and tools. The NIST request for information on securing AI agent systems identifies risks from adversarial data, insecure models, specification gaming and unconstrained deployment access. It also asks how existing cyber practices should be adapted rather than discarded.
A practical gate starts with identity. Each agent instance needs a named owner, a traceable initiating user or service and credentials that expire. Delegation should narrow authority rather than silently inherit everything the human can do. Tool calls should be allow-listed, rate-limited and logged, with separate approval for irreversible actions.
Memory needs its own boundary. Teams should know what enters persistent memory, who can change it, how poisoning is detected and how a contaminated state is rolled back. For physical systems, the boundary must include safe states, manual override and separation between a recommendation and an actuation command.
A checklist is not assurance
The counterargument is straightforward: mature organisations already use threat modelling, zero trust, software supply-chain controls and incident response. A new AI-specific checklist can duplicate controls or create false confidence through box-ticking. That risk increases if the final guide treats all agents alike, from a read-only research assistant to a system operating industrial equipment.
The answer is not more boxes. It is evidence tied to risk. A low-impact agent may need logging and a narrow data boundary. A state-changing agent should also require test cases for prompt injection, confused-deputy behaviour, credential misuse, memory poisoning and recovery. A physical agent needs independent safety interlocks that do not depend on the model following an instruction.
Leaders can therefore prepare a one-page deployment gate now: intended task, data classes, tools, permissions, reversible versus irreversible actions, human approval points, monitored failure modes, incident owner and rollback test. When KISA publishes its guide, map each requirement to that evidence and record gaps instead of treating publication as automatic readiness.
The gate should also state how assurance changes with autonomy. A read-only assistant might be reviewed quarterly, while an agent that transfers funds, changes access or controls equipment may need pre-action approval and continuous monitoring. This makes the checklist a routing mechanism for scrutiny, not a universal certificate. It also prevents a low-risk pilot from inheriting the same burden as a safety-critical deployment—or the reverse.
The Skills Atlas can clarify which security, operational and domain skills must sit around the system. The near-term decision is simpler: no autonomous action in production without an attributable identity, bounded authority, observable behaviour and a tested way to stop and recover it.
A minimum evidence package
Retain the exact model, system prompt, connectors, tool versions, credentials, memory configuration, test data, approval path and rollback result. Define which outcomes are prohibited and which failure rate blocks launch. Separate model quality from system security and physical safety. Re-run the gate after any material change, and keep a human route to challenge outcomes that affect work, opportunity or rights.