What does the security architecture of AI agents actually look like?

Talking Shop
1

As agent systems move into real workflows, security concerns go beyond
simple prompt guardrails.

From what I’ve been observing, agent security tends to involve several
layers around the orchestration framework:

1 Runtime safety
2 Data protection
3 Execution integrity
4 Auditability
5 Governance

I tried sketching a simple architecture to visualize where these layers
sit relative to the agent runtime.

Curious if this matches what others are seeing in production systems.

2

I found this white paper to be really helpful on the topic: The Agentic AI Security Scoping Matrix: A framework for securing autonomous AI systems | AWS Security Blog

4

agent-architecture-map
agent-architecture-map276×958 27.2 KB

5

@joy7758 Nice will have a look at it.

6

The layering you sketched matches what I’ve been thinking through too, but I’d draw a sharper line between execution integrity and auditability. Those tend to get collapsed but they’re solving different problems.

Execution integrity is a runtime concern: did the agent act within its sanctioned scope, under the right policy, given the actual inputs it saw? That needs to be captured *before* the action completes otherwise you’re reconstructing it after the fact from logs you don’t fully trust.

Auditability is a downstream concern: can someone else (compliance team, a counterparty, a regulator) independently verify what happened, without trusting your database or your observability stack?

Most implementations conflate the two and end up with auditability that depends entirely on the integrity of the logging system itself. If the logs live in the same infrastructure as the agent, you haven’t really separated the concerns.

The architecture I’ve found cleanest for this: seal the inputs snapshot + ruleset hash + reasoning trace into an HMAC *before* execution, store the receipt separately, and expose a verify endpoint that any counterparty can call independently. The verification doesn’t need to trust the agent host…it just needs the receipt ID and the public verify endpoint.

Curious what layer you found hardest to get right in practice — in my experience the governance layer is well-theorized but the execution integrity layer tends to be where real implementations break down.

7

Thanks for sharing this — the AWS matrix is a useful way to classify agent systems by autonomy and security scope.

Most frameworks I’ve seen focus on defining security controls around the level of agency.

The angle I’ve been exploring is slightly different: what happens at runtime when the agent actually executes actions.

In practice a lot of failures are not just prompt issues but action issues — the agent calls a tool or triggers a workflow that turns out to be wrong.

So I’ve been thinking about an execution-integrity layer that sits between the agent and external systems.

agent → execution integrity → tools / APIs

The idea is to validate and log actions before they reach real systems, and make the execution trace deterministic so the whole chain of decisions can be reconstructed later.

I’ve been experimenting with this here:

Still early exploration, but the goal is to make execution traces portable across agent frameworks.

8

Hello @joy7758, apologies for the late reply; I completely missed this thread.
I loved your idea about the execution integrity layer, but for LangChain, have you thought about wrapping it up in dedicated middlewares?
Each Layer get’s own dedicated middleware. I know you want to make it framework agnostic, but for langchain giving support for Middleware might be a great idea.

9

Thanks — yes, that is exactly the direction I’m considering.

My intention is to keep the core execution-integrity model framework-agnostic: a minimal profile for action validation, execution receipts, trace hashes, and later verification.

But I agree that for LangChain, a dedicated middleware adapter would be the cleanest implementation path.

The structure I’m thinking about is:

  1. a framework-neutral execution receipt / profile;
  2. a LangChain middleware that intercepts tool calls;
  3. pre-action validation before the tool/API is executed;
  4. deterministic logging of the action context, policy/ruleset hash, and result;
  5. a small validator that can verify the receipt independently.

So the LangChain middleware would not replace the portable profile — it would be a reference implementation of it.

I’ll probably start with a minimal middleware demo around wrap_tool_call, since the action/tool boundary is where execution-integrity failures usually become concrete.

10

Sounds great, it will be great if you can mark your plan as a solution so this thread get’s closed down.