Preparing for an AI Agent Security Workshop

The most useful thing to bring to an AI agent security workshop is a workflow the team is actually trying to ship. “We want to understand AI risk” leaves too many directions open. “We want this support assistant to read one customer's documents and draft a reply” gives the group something concrete to examine.

I would aim for a session that ends with a smaller set of unresolved decisions, a few reproducible checks, and named owners. Participants should be able to use the outputs in engineering work the next morning. A dramatic prompt-injection demonstration can start a discussion, but it does not establish which controls the team needs.

This guide supports the AI security workshop with a proposed agenda and local exercises participants can adapt to a real workflow. Use it to agree on the system boundary, prepare the relevant artifacts, and identify the decisions the session needs to resolve.

Choose one workflow and one decision

For the examples here, use a hypothetical support assistant that reads tenant-specific company documents and proposes edits. It may draft a customer reply, but sending requires an approved action through a separate channel. Deletion, sharing-policy changes and arbitrary command execution are unavailable.

The decision for the workshop is whether the proposed pilot has a sufficiently clear permission boundary to proceed to implementation and testing. The group is not approving live customer access during the exercise.

Write a short brief before the session:

This structure is consistent with the context-setting work in NIST's AI RMF 1.0. It is a workshop design choice, not a NIST-approved curriculum or certification.

Bring the people who own the controls

The engineer who owns the dispatcher can explain tool validation. The identity owner can explain delegated versus workload access. The product or operations owner can say whether a proposed denial makes the workflow unusable. A security reviewer can turn the disagreement into a test.

One person may fill several roles on a small team. The requirement is that each decision has an owner, including approval behavior, document permissions, logs, rollout and recovery. Include privacy or legal participants when the workflow raises questions about data handling or external commitments; give them the actual data flow and proposed terms rather than asking them to interpret a demo.

Send the brief, a current architecture sketch, a tool inventory and known open questions in advance. Use redacted configuration summaries. Participants do not need production credentials or real customer records for these exercises.

Prepare the local environment

The reference files use Python 3.10 or later and the standard library. They require no model account, package installation or network connection. Download the document policy example, credential lifecycle example and RAG boundary example, then inspect and run them before the session.

python3 document_permissions.py
python3 credential_lifecycle.py
python3 rag_boundaries.py

The reference run on September 9, 2026 passed 14, 8 and 8 tests respectively. These counts describe the supplied local examples. They do not score a participant's product. If a participant cannot run Python, they can follow the fixture inputs and expected outcomes with another participant; access to production systems should not become a prerequisite.

A proposed three-hour agenda

Reserve enough time for the final decisions. If the system diagram consumes the session because no one knows the credential path, that is useful information. Reduce the exercise scope and document the gap instead of rushing through every activity.

Exercise 1: approve the exact edit

Maya belongs to tenant Amber and can edit DOC-001. Lee is the authorized reviewer. Start with a permitted read, then propose an edit with a specific body and document version. Confirm that the write fails until Lee's trusted approval exists.

Change one condition at a time: the body after approval, the tenant, an unexpected argument, the document version, or Maya's editor access. Record whether denial occurred before the write. Revoke Lee's reviewer permission and retry the original approval. A past approval must not silently override the current policy.

The group should decide which fields a real approval preview needs, which identity supplies them, and how version checks and approval consumption would be coordinated in the real service. The local example is single-threaded; production race conditions remain an implementation task. The secure tool-access guide explains the policy in more detail.

Exercise 2: follow one document through retrieval and citations

The RAG fixture has Amber and Birch tenants plus an Amber note containing an inert instruction to send documents elsewhere. Confirm that each subject can retrieve their own marker, then query the other tenant's marker. Feed an unauthorized candidate directly into the context builder to exercise the second check.

Next, retrieve an allowed candidate and revoke its ACL before building context or citations. Inspect titles and source URLs as well as body text. A confidential matter name in a citation is still information disclosed to the user.

Finally, inspect the hostile note. The fixture preserves it as untrusted source text and denies a synthetic send proposal because sending is unavailable. There is no language model in the program. Participants should explain what was demonstrated: current ACL filtering, citation filtering and absence of a send capability. They should also name what remains untested: model behavior, vector retrieval, external reranking, answer caching and provider retention.

Exercise 3: revoke a grant and stop the workflow

Run a permitted fixture request, revoke the handle, and retry it. The expected result is a denial with no additional downstream-call record. Test the replacement handle and verify that the old one stays denied.

Then move from code to a tabletop discussion. Who disables the connector in the actual application? What happens to a worker with a cached token? Which operations may already be in flight? Who receives incomplete tasks? What confirms that the provider stopped accepting the grant?

The fixture cannot answer those deployment questions. Use them to assign follow-up tests with a measured revocation target. Do not assume that deleting local token storage invalidates a previously issued access token everywhere.

Leave with artifacts someone can maintain

A useful participant packet contains the annotated workflow diagram, a tool/credential matrix, the test inputs and observed results, and a short decision log. Each unresolved issue should have an owner, an acceptance criterion and a target review point. Separate implementation gaps from policy decisions: missing ACL checks need code; deciding which edits require approval needs a responsible business owner as well.

Keep a short list of material changes that reopen the review, such as a new connector, broader scope, a send capability, a model change or a new retrieval cache. A workshop can help the team agree on those boundaries. Verification of the resulting implementation is the next piece of work, scoped to the application and its actual operating environment.