AI Employee Security Checklist for a Production Pilot

§ 01The Production-Pilot Checklist at a Glance

The NIST AI Risk Management Framework organizes AI risk work across Govern, Map, Measure, and Manage and treats it as a continuous lifecycle activity. The NIST Cybersecurity Framework 2.0 adds a complementary cybersecurity view across Govern, Identify, Protect, Detect, Respond, and Recover. Neither framework is a product checklist or a guarantee. Together, they support the discipline behind this gate: define the context, choose outcomes, implement controls, measure them, manage gaps, and keep the decision current.

Build one evidence register

For every item, record: a checklist ID; the requirement as an observable security outcome; scope; control mechanism; owner; evidence; test method and result; versions; result (pass, fail, or accepted exception); gap; decision; and expiry.

Evidence should be: specific to the proposed pilot; generated from the current configuration; independently reviewable; tied to an owner and time; reproducible where possible; protected from unauthorized modification; and sufficient to explain both control decisions and real effects.

Separate platform evidence from deployment evidence

A vendor may prove that a feature exists. The buyer must still prove that the feature is configured correctly in the buyer’s environment.

Approve the deployment evidence.

§ 02Apply Hard Stops Before the Checklist

Some conditions should stop a pilot without balancing them against strengths elsewhere.

The AI employee risk assessment provides the preceding role-level decision across consequence, scale, data, authority, reversibility, detectability, uncertainty, and propagation. This checklist assumes the role is potentially acceptable and asks whether the launch controls actually exist.

Do not average away a critical failure

A secure connector does not compensate for: an over-privileged service account; invisible memory writes; an arbitrary external destination; approval that can be reused; missing audit lineage; a kill switch that has never been tested; or an incident plan with no owner.

Track both the overall decision and the worst unresolved item:

Define exception rules before exceptions appear

An accepted exception must include: the failed requirement; a concrete risk scenario; affected people, data, systems, and actions; pilot scope; the reason remediation is not complete; compensating controls; monitoring and alert; an accountable risk owner; a remediation owner; a deadline; automatic expiry; reapproval conditions; and a stop condition.

“Low risk,” “temporary,” “vendor limitation,” and “pilot only” are not complete exception rationales.

§ 03Govern the Role, Scope, and Accountability

Approve a role card before approving technology access.

The AI employee permissions and approvals guide converts this operating boundary into specific grants, denials, and action-bound decisions.

Assign distinct owners

One person may hold several roles in a small organization, but the responsibilities remain distinct: business owner (purpose, accepted outcome, operating fit, affected parties); process owner (procedure, source-of-truth, exception and completion rules); security owner (threat model, identity, permissions, tests, monitoring, response); privacy/data owner (data authority, minimization, access, retention, rights handling); system owner (connected application controls and downstream effects); model/platform owner (model, prompt, orchestration, memory, tool configuration); reviewer (consequential or uncertain action decisions); incident commander (containment, coordination, evidence, recovery, resumption); and vendor owner (contract, due diligence, change notices, support and exit).

Record alternates and on-call coverage. A scheduled worker should not continue consequential work when its required owner is unavailable.

Define the pilot boundary

Use:

one role + one workflow + one environment + named sources + named tools + fixed destinations + bounded volume + fixed period

Good pilot boundaries include: one business unit; one synthetic or low-sensitivity data set; one staging or limited-production workspace; one task class; one connector account; one approved recipient domain; one maximum daily volume; one approval group; one set of dashboards and alerts; and one start and end date.

Do not quietly add a second workflow because it uses the same connector. New purpose, data, tool, destination, or consequence requires change review.

Record prohibited outcomes

Examples: no final employment, lending, insurance, healthcare, legal, or other high-impact decision; no irreversible deletion; no permission administration; no security-control bypass; no unapproved external publication; no unrestricted code execution; no credential collection; no movement of data outside approved systems or regions; no autonomous contract acceptance; no procedural memory change from external content; and no child agent with greater authority than its parent task.

Prohibitions should be enforced in identity, permission, and tool policy - not left as prose alone.

§ 04Inventory Architecture, Data Flows, and Dependencies

Draw the deployed system, not the sales diagram. Include: the user and requester; AI employee and orchestrator; model provider; prompts and policies; context assembler; retrieval and search; memory stores; task state and queues; connectors and APIs; browser or desktop sessions; identities and tokens; approval service; tool-execution boundary; downstream applications; logs and observability; incident controls; vendors and subprocessors; and backup, export, and deletion paths.

The CISA and NCSC Guidelines for Secure AI System Development apply secure-by-design principles across design, development, deployment, and operation. For a buyer, the immediate implication is that platform security cannot be separated from connector configuration, identity, deployment architecture, monitoring, and operating ownership.

Map trust boundaries

For each flow, record: source actor; source system; destination; purpose; data class; instruction role; identity; protection; persistence; region/vendor; evidence; and deletion path.

Check: every production data source appears on the map; every external and internal destination appears on the map; instruction, content, secrets, and generated output are distinguished; model-provider and application-layer persistence are separated; handoffs and agent-to-agent flows are included; logs, indexes, caches, summaries, exports, and backups are included; and unknown or undocumented flows block launch.

Inventory components and supply chain

For each component - model and version, orchestration, prompt/policy, retrieval, memory, connector, tool, browser/desktop, approval, monitor, external package, vendor/subprocessor - record how it is approved, versioned, authenticated, patched, monitored, revoked, replaced, rolled back, and removed at pilot end.

Define authoritative systems

Memory, chat, a generated summary, and a task board should not silently replace a system of record.

The worker may propose. The authoritative system determines current state.

§ 05Secure Identity, Permissions, and Secrets

Use a dedicated workload identity for each role or security boundary. Do not share a human owner account, administrator token, or one catch-all service account across unrelated workers.

Checklist: the agent identity is distinct and attributable; the initiating human or system principal is preserved; authentication uses supported non-shared methods; permission is evaluated for agent, principal, task, object, action, and context; high-risk roles use stronger authentication and session controls; dormant, orphaned, or duplicate identities are detected; access reviews include agent identities and connector grants; offboarding or pilot closure disables identity and tokens; child agents do not inherit bearer credentials from the parent; and emergency access is separate, monitored, and time-limited.

Enforce least privilege across multiple dimensions

The least-privilege guide for AI agents provides the design and test method for these dimensions.

For every grant: the business purpose is recorded; resource and function are explicit; write access is separated from read access where possible; administrator functions are excluded; wildcards and inherited permissions are justified; time and volume limits exist; access expires automatically; denied adjacent actions are tested; and revocation is tested while work is active.

Protect secrets and sessions

Secrets include API keys; OAuth tokens; session cookies; passwords; private keys; database credentials; webhook secrets; signing material; recovery codes; and temporary authorization links.

The model should not need to read a raw secret to use a narrow authorized function.

Test authorization, not only authentication

Test: correct identity, correct object, allowed function; correct identity, wrong account; correct identity, prohibited field; correct identity, expired approval; correct identity, outside shift; child identity, parent-only resource; revoked identity during a long-running task; connector token with reduced scope; duplicate or replayed action; and an incident state that requires all consequential actions to stop.

Record both denial and the absence of side effects.

§ 06Protect Inputs, Data, Context, and Memory

Data security begins before the model receives context.

Classify input roles

Checklist: source and instruction role survive ingestion and retrieval; untrusted content cannot redefine role, policy, permission, destination, or approval; input type, size, schema, source, and freshness are validated; malformed and unsupported content has a safe fallback; parser, OCR, image, metadata, and hidden-layer behavior is tested; tool responses and agent handoffs are treated as new inputs; and prompt-injection monitoring is not the sole control.

The prompt-injection guide for persistent AI employees threat-models the path from untrusted content to private context, tools, memory, and delegated action.

Minimize data

For every field: Is it needed for this task? Is a less sensitive value sufficient? Can the model receive a reference instead of the full value? Can public research and private analysis be separated? Can the work be completed in a lower-trust environment? Does the output need the source data? Who may receive the result? How long should any copy persist?

Gate memory

Memory can affect future work, so treat writes and retrievals as security decisions. Require every material memory record to carry: purpose; type; source; status; scope; sensitivity; owner; effective period; conflict state; correction path; and deletion path.

Checklist: external content cannot directly create procedural memory; unverified claims remain attributed candidates; memory-write permission is narrower than ordinary task execution; cross-tenant, cross-account, and cross-role reads are denied by deterministic access control; retrieval rechecks scope, freshness, status, and safety; users and owners can inspect, correct, suppress, and delete appropriate records; provenance survives summaries and handoffs; recursive promotion through another agent is blocked; memory lifecycle operations are logged; and poisoning, stale retrieval, correction, deletion, and rollback are tested.

The AI memory privacy and retention checklist covers the wider lifecycle across purpose, notice, minimization, access, retention, correction, deletion, processors, monitoring, and incident handling.

Verify provider and product data handling

Ask: Which data reaches each model provider? Is it used to train or improve provider models? Which retention applies to inference requests? Where is it processed and stored? Which humans or subprocessors can access it? Which application-layer memory, files, task state, artifacts, and logs persist separately? Which deletion actions apply to each layer? How are backup and legal/security retention handled? How are account closure and export handled? What changes require customer notice?

“Provider does not train on business data” does not answer application memory, connector storage, logs, or deletion.

§ 07Constrain Tools, Actions, and Approvals

Every consequential capability should have a narrow tool contract covering: function; caller; objects; parameters; data; destination; limits; approval; idempotency; precondition; postcondition; failure; and evidence.

The AI agent guardrails guide explains why critical boundaries should be enforced across identity, policy, tools, execution, monitoring, and response rather than through one prompt or filter.

Narrow functions

Checklist: unused tools are absent, not merely discouraged; read, draft, write, send, delete, and administer are separate; free text cannot select arbitrary functions or destinations; generated parameters are schema-validated; authorization is checked immediately before execution; current state and version are checked; tool output is treated as untrusted; duplicate actions are prevented; partial and ambiguous results trigger read-back; and side effects and after-state are verified.

Design meaningful approval

Approval should answer:

May this actor perform this exact action on this exact object, with this exact data, to this exact destination, now?

The packet must show: role and initiating principal; current goal; material source evidence; proposed function; affected object; current and proposed state; data to be disclosed or changed; the actual recipient or destination; uncertainty and policy exceptions; expected consequence and reversibility; postcondition; approval expiry; and alternative actions.

Checklist: the reviewer is authorized and independent where required; the reviewer has time and source evidence; approve, reject, modify, clarify, and escalate are real options; approval is single-use where appropriate; material parameter change invalidates approval; absence or timeout fails safely; the worker cannot approve its own exception; and the approval event is attributable and immutable enough for investigation.

Bound autonomous execution

Before bounded execute: the action is reversible or containable; consequence and affected scale are low enough; input and object identity are reliable; the tool is narrow and typed; the destination is fixed or deterministically resolved; limits and breakers exist; the postcondition is machine-verifiable; monitoring is timely enough; revocation works during execution; failure routes to a safe state; and the exact scenario passed deployment-like tests.

If any item is missing, use draft or approval-required mode.

§ 08Make Logs, Monitoring, and Kill Paths Operational

The organization should be able to reconstruct: who or what started the work; which role, version, model, and policy ran; which sources and memory influenced the decision; which data was accessed; which permissions and approvals applied; which tools, objects, parameters, and destinations were proposed; which action actually executed; what changed in the real system; which memory, task, or handoff state was created; and which alerts fired, and who responded.

The AI employee audit-log guide defines an event model for reconstructing decisions, actions, and effects from observable evidence rather than opaque internal model state.

Log structured events

Log task creation; context retrieval; memory reads/writes; plan and action proposals; authorization; approval; tool execution and results; handoffs; control events; alerts; response actions; and changes.

Checklist: events use synchronized time and stable correlation IDs; actor, task, run, object, and lineage can be joined; logs distinguish proposal, approval, execution, and result; sensitive fields are minimized or protected; log access and modification are controlled; retention matches investigation and privacy needs; export is possible without losing structure; and missing or delayed telemetry has a defined response.

Monitor four layers

Security signals include: a new destination or domain; unusual data retrieval followed by external transmission; tool use outside normal sequence; cross-account access attempts; unexpected permission or token changes; memory writes from public or unknown sources; procedural-memory updates outside change control; repeated denied actions through different routes; abnormal volume, spend, retries, runtime, or delegation depth; reviewer and requester identity anomalies; log gaps; and breaker failures.

Test kill paths

A kill path should stop effect, not only hide the interface.

Measure time from decision to effective containment. A button labeled “pause” is not sufficient.

§ 09Test Security in Deployment-Like Conditions

Capability tests ask whether the worker can complete the task. Security tests ask what happens when identity, input, context, permission, tool, human, system, or model behavior departs from the happy path.

The OWASP Top 10 for LLM Applications 2025 covers prompt injection, sensitive information disclosure, supply chain, data/model poisoning, improper output handling, excessive agency, prompt leakage, vector/embedding weaknesses, misinformation, and unbounded consumption. The OWASP Top 10 for Agentic Applications adds agent-goal hijack, tool misuse, identity/privilege abuse, agentic supply chain, unexpected code execution, memory/context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents. Use them as threat inputs, then test the buyer’s actual workflow.

Use a minimum test matrix

Use synthetic identifiers, canary records, controlled inboxes, fixed destinations, staging APIs, and reversible objects. Never use live credentials or uncontrolled external endpoints for adversarial testing.

Define expected results before testing

Each case needs: an objective; setup; stimulus; expected model behavior; expected system behavior; a forbidden effect; evidence; cleanup; an owner; and a retest trigger.

Contained results may support a narrow pilot if the independent control is robust and the residual risk is accepted. Detected-late, silent, and untestable critical paths should block launch.

Test usability and human control

Security fails when users cannot understand or operate the control. Test whether: requesters know the worker’s scope; reviewers understand the source, action, data, and consequence; approvals are not so frequent that they become automatic; block reasons support a safe next step; users can stop suspicious work; security can find and contain a role quickly; corrections reach downstream state; incident staff can use the logs; owners recognize a material change; and affected people can reach required review or recourse.

Retest after material change

Retest when any of these changes: the role or purpose; model or provider; system or task prompt; retrieval source, parser, index, or ranking; data class or field; identity or permission; connector or browser access; tool function or parameter; destination; memory schema or policy; approval trigger or reviewer; delegation topology; monitoring or breaker; downstream application; vendor/subprocessor; or an incident lesson.

One passed pilot does not approve a materially different configuration.

§ 10Prepare Incident Response and Recovery

Define incident triggers before production: unauthorized access or attempted privilege escalation; suspected prompt injection with a reachable sensitive sink; data disclosure or wrong recipient; corrupted or poisoned memory; unapproved production change; repeated unsafe tool attempts; unexplained task, goal, or procedure changes; cross-account or cross-tenant access; rogue or looping delegation; lost audit visibility; credential, token, or connector compromise; unexpected spend or resource consumption; model/provider changes with control regression; and complaints or impact involving an affected person.

The AI employee incident-response guide provides the operating sequence for pause, revoke, preserve, scope, correct, notify, recover, validate, and resume.

Checklist: severity and escalation criteria are written; business, security, privacy, legal, communications, vendor, and system owners are reachable; pausing and revocation do not depend on the affected agent; evidence sources and access are known; memory and derived-state propagation can be traced; manual fallback exists for critical work; customer or affected-party handling is defined where applicable; vendor escalation and response commitments are recorded; and resumption requires a named decision and evidence.

Define recovery objectives

For the pilot, specify: maximum acceptable time to contain; maximum acceptable affected volume; the authoritative recovery source; the minimum service that must continue; a safe manual process; state that can be rolled back; state that must be corrected forward; recipients or systems requiring follow-up; the monitoring period after restoration; and conditions that require permanent retirement.

Recovery is not “restart the agent.” It is restore correct business state and prove that the unsafe path is closed.

Run a tabletop and a technical drill

Tabletop: walk through one realistic incident; test ownership, communication, decision rights, and evidence needs; identify policy and contract gaps.

Technical drill: introduce harmless synthetic bad state; verify the alert; pause the role; revoke access; suppress affected memory; trace descendants; restore authoritative state; verify absence of further action; and resume a safe subset. Record the timeline and missed steps.

§ 11Verify the Vendor and the CellCog Deployment

A vendor review should connect written claims to deployed proof.

The platform comparison guide helps buyers compare the wider operating system. This checklist makes security proof a launch requirement.

Apply the checklist to CellCog

CellCog publicly describes AI Employees with goals, schedules, permissions, connected accounts, memory, task boards, handovers, browser or desktop work, and employee-to-employee collaboration. Those capabilities create both useful control points and deployment responsibilities.

As of July 29, 2026, verify in the live product and contract: how a role and prohibited outcomes are represented; how each employee identity and initiating user are attributed; which connector scopes and downstream permissions apply; how secrets and authenticated sessions are handled; whether browser, email, files, connectors, and tool responses retain source trust; where prompt-injection and output-safety controls operate; how arbitrary tools, objects, fields, and destinations are restricted; how approval binds to the exact proposed effect; which memory types, write gates, scopes, corrections, retention, and deletion paths exist; how parent and child employee authority and context are separated; which events can be viewed or exported; how alerts and breakers are configured; how one task, employee, connector, token, or memory set is stopped; which deployment tests CellCog can demonstrate; which changes require notice; and how account closure and data exit work.

Review the current CellCog privacy policy for described data practices and the current terms of service for contractual allocation, restrictions, and user responsibilities. Public text does not prove a control works in the proposed configuration. Resolve gaps through demonstration, written response, contract, technical testing, or a narrower pilot.

Ask for one end-to-end proof

Use a harmless scenario: (1) an authorized user creates a bounded task; (2) the worker retrieves approved data plus marked untrusted content; (3) the worker proposes an action outside policy; (4) tool policy denies it; (5) the monitor alerts; (6) the owner inspects source, decision, denial, and state; (7) the memory gate prevents unsafe persistence; (8) the role is paused; (9) the connector is revoked; (10) evidence is exported; and (11) safe work resumes after review.

One trace should show every identity, source, policy, tool, memory, alert, and response event.

§ 12Complete the Pilot Decision

Use a four-stage launch:

Do not skip a stage because a vendor has other customers in production. The buyer’s data, systems, policies, and consequences are different.

The AI employee pilot guide defines the wider experiment: baseline, representative cases, operating modes, outcome metrics, decision thresholds, final report, and go/revise/switch/stop decision. This security checklist supplies the non-negotiable control and evidence gates inside that experiment.

Use a 30-day evidence plan

Sign the launch record

Include: the role and use case; environment; data classes; identities and permissions; sources, tools, destinations, and limits; autonomy level; model, prompt, policy, connector, and control versions; checklist results; test summary; open findings; accepted exceptions; monitoring and response ownership; pilot start/end; review cadence; stop conditions; change triggers; the decommissioning plan; and signatures or recorded approvals from accountable owners.

§ 13Final Security Checklist

Govern and scope

• Purpose, accepted outcome, allowed tasks, prohibited outcomes, and affected parties are explicit.
• Business, process, security, privacy/data, system, platform, reviewer, incident, and vendor owners are named.
• Pilot is bounded by role, workflow, environment, sources, tools, destinations, volume, and time.
• Hard stops pass.
• Every exception has risk, scope, controls, owner, monitoring, deadline, and expiry.

Architecture and supply chain

• Data, instruction, model, context, memory, connector, tool, approval, log, vendor, and deletion flows are mapped.
• Trust boundaries and authoritative systems are defined.
• Components, versions, dependencies, subprocessors, regions, and change processes are inventoried.
• Unknown data or action paths block launch.

Identity, authority, and secrets

• Worker has a dedicated attributable identity.
• Initiating principal is preserved.
• System, resource, field, function, action, destination, time, volume, spend, concurrency, delegation, and environment are least-privileged.
• Denial, expiry, and active revocation are tested.
• Secrets stay outside prompts, memory, tasks, artifacts, and ordinary logs.
• Tokens are minimal, short-lived where possible, rotated, and revocable.

Data, context, and memory

• Data purpose, authority, classification, minimization, access, transfer, retention, and deletion are defined.
• Governing instructions, trusted data, external content, secrets, and generated output are separated.
• Prompt-injection paths cannot bypass deterministic action and memory controls.
• Memory writes and retrievals enforce purpose, source, status, type, scope, sensitivity, owner, freshness, correction, and deletion.
• Cross-account, cross-tenant, cross-role, poisoning, stale, correction, and deletion tests pass.

Tools and human control

• Consequential tools are narrow, typed, validated, authorized, and bounded.
• Arbitrary functions, objects, destinations, code, and retries are blocked.
• Approval shows exact actor, source, data, object, action, destination, risk, and expiry.
• Material change invalidates approval.
• Postconditions prove the actual business state.
• Draft or approval-gated mode remains the fallback.

Detect, respond, and recover

• Structured logs reconstruct source, context, memory, policy, approval, tool, result, and handoff.
• Work, control, system, and impact monitoring is configured.
• Alerts reach named owners and missing telemetry has a response.
• Pause, revoke, block, suppress, preserve, contain, restore, and resume controls are tested.
• Tabletop and technical incident drills are complete.
• Manual continuity and recovery objectives are defined.

Test, decide, and maintain

• Normal, boundary, malformed, adversarial, permission, data, memory, tool, approval, delegation, resource, monitoring, and recovery cases pass.
• Tests record deployment versions and actual system effects.
• Open failures block or narrow launch.
• Vendor claims are backed by deployment evidence.
• Launch record is signed by accountable owners.
• Material change and incident triggers cause reassessment and retesting.
• Pilot closure revokes access and disposes of data and state.

If any checked item depends on a verbal assurance, mark it unverified until evidence exists.

The production decision is not “Is the AI employee safe?” It is:

Does the evidence justify this exact worker performing this exact task, with this exact data and authority, inside these limits, while we can detect failure, stop effect, reconstruct events, and recover?

If the answer is incomplete, narrow the pilot until it becomes provable.