Tutorial 4: AWS SAM Client + Agentic

We have two goals in this tutorial:

1. Get you using a non-built-in diagram environment

2. Get you shaping a specification for an agentic serverless system

In this walkthrough we are going to download an environment file from the iSecureByDesign developer repository, import it into the app, and then model a small AWS SAM client-side architecture where an Agentic Serverless Function is allowed to interact with a DynamoDB datastore, with an API Gateway in front of it.

The main architectural rule we want to express is simple:

  • the agentic serverless function can access the datastore
  • no other component should be allowed to touch that datastore directly

Stage 1: Download the diagram environment

This tutorial starts outside the app. Open the iSecureByDesign developer repository:

Find the diagram environment called AWS Sam Client + Agentic and download the environment file to your machine.

If you want more background on imported environments, see:

Stage 2: Import the environment

In the app:

1. Open Settings

2. Open Diagram Environments

3. Import or upload the environment file you downloaded

4. Confirm that AWS Sam Client + Agentic now appears in your available environment list

Once it is available, create a new project and select that environment.

Expected result:

  • your project shows the correct environment name and version badges
  • the component library reflects the imported environment rather than only the built-in ones

Stage 3: Create the initial architecture

With the new project open on the diagram page, add these core components:

  • API Gateway
  • Agentic Serverless Function
  • DynamoDB

Now connect them so the shape reflects the intended design:

1. API Gateway -> Agentic Serverless Function

2. Agentic Serverless Function -> DynamoDB

At this point, do not connect any other component to the datastore. The goal is to make the function the only direct path to that storage.

Expected result:

  • the API surface sits at the edge
  • the function is the execution point for the agentic logic
  • the DynamoDB datastore is downstream of the function only

Stage 4: Make the datastore exclusive to the function

The important design idea in this tutorial is that the datastore is not a shared free-for-all data store. It should be owned operationally by the agentic function.

So review your diagram and make sure:

  • there are no direct connections from API Gateway to DynamoDB
  • there are no other compute components connected to that datastore
  • the DynamoDB component remains attached only to the Agentic Serverless Function

This gives the specification a much clearer story:

  • inbound requests arrive through the gateway
  • execution happens in the function
  • storage access is mediated by that function alone

This is the kind of architectural intent that becomes much more useful later when generating implementation plans and reviewing outputs.

Stage 5: Explore scope and controls

Now start exploring the context menus for the gateway, the function, the bucket, and the connections between them.

Set the scope values so the model is actually assessed rather than left in an alert or not-assessed state. Then start looking at controls.

Do not treat this tutorial as a single required control set. The point is to explore what makes sense for your use case. For example, you may want to think about:

  • request validation at the API edge
  • authentication and authorization
  • encryption in transit
  • encryption at rest
  • secrets handling
  • logging and traceability
  • approval or safety controls around agentic behaviour
  • timeout, retry, or failure-handling choices

One especially useful thing to try is adding authentication to the components that make sense for your design, particularly at the API edge and anywhere the agentic function is expected to operate behind an authenticated boundary. Even if you are just experimenting, this usually improves the downstream specification because it gives the spec a clearer story about who is allowed to call what.

For this tutorial, go a bit further and make those decisions explicit on the DynamoDB component. Open the DynamoDB context menu and set:

  • Authentication Mode = awsIam
  • Authorization Model = iamPolicy
  • Least-Privilege IAM = enabled
  • No Wildcard IAM Grants = enabled

Then select the connection between the Agentic Serverless Function and DynamoDB and enable:

  • Least-Privilege Interaction = enabled

This is a good example of how a few concrete control choices can materially improve the generated specification. Instead of just saying that the function talks to a datastore, the spec can now carry more precise expectations around authenticated access, IAM policy shape, and constrained interaction between the function and the database.

The right answer depends on what kind of agentic function you are trying to build. The value of the environment is that it gives you a stronger starting point for asking those questions.

Stage 6: Move into specification workflow

Once the diagram shape and controls are in a reasonable state, go to Workflow and open Specification.

Review the generated specification carefully. In this environment the specification is not just describing a generic serverless application. It should be framing an agentic execution component, its surrounding AWS architecture, and the constraints implied by your modelling choices.

Things to look for:

  • does the API Gateway appear as the ingress point?
  • is the Agentic Serverless Function clearly the execution component?
  • is DynamoDB represented as downstream storage?
  • does the spec preserve the idea that only the function should access the datastore?
  • does the spec now reflect authenticated and least-privilege access expectations for DynamoDB?

If not, go back to the diagram and refine the structure or controls.

Stage 7: Generate outputs for an AI coding tool

From Outputs, either:

  • generate outputs directly if you have AI configured inside the app, or
  • copy the outputs prompt/specification and use it with your preferred external model

For this sort of environment, the generated outputs will often be most useful as:

  • an implementation plan
  • a tasks.md
  • a build sequence for an AI coding tool

That is usually a better starting point than asking an AI to jump straight to code with no architecture contract.

Stage 8: Evaluate and iterate

Once you have generated outputs, move through the reviewer/evaluation stages and compare the outputs back to the specification.

Use this stage to ask practical questions such as:

  • did the output preserve the gateway -> function -> DynamoDB flow?
  • did it keep datastore access limited to the function?
  • did it include the controls you expected?
  • are there controls you now want to add to the model before regenerating?

That last point matters. This tutorial is not only about producing one result. It is about learning how imported environments, architectural intent, and control choices combine to shape a better specification for an agentic system.

Next step

Once you are comfortable with this pattern:

  • expand the architecture with additional AWS components if needed
  • try different controls on the function and gateway
  • compare the resulting specification and outputs after each change
  • experiment with different implementation prompts and AI coding tools

The more deliberately you model the boundaries and controls up front, the more useful the downstream specification becomes.