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.
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
@joy7758 Nice will have a look at it.
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.
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.
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.
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:
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.
Sounds great, it will be great if you can mark your plan as a solution so this thread get’s closed down.
Solid framework, and the execution-receipt approach is the right level of abstraction for layers 3 and 4 in your taxonomy. The framework-agnostic profile + LangChain reference implementation is clean.
One observation from running similar architectures in EU production: the tool-call boundary catches integrity failures, but it’s downstream of where most modern attacks actually originate. The 5-layer model holds up better if layer 1 (runtime safety) and layer 2 (data protection) have their own intercept point upstream of the tool call.
Concretely, a prompt injection hidden in a retrieved document, or a PII leak in an LLM output, never trips a tool-call interceptor. Both happen in the LLM round-trip itself, before any tool is invoked. By the time the wrap_tool_call hook fires, the agent has already been compromised (in the injection case) or already leaked data (in the PII case).
What I’ve found works as a complement to your design: a transparent reverse proxy on the LLM provider boundary (network path, not LangChain runtime) that scores every input and output against a shield suite, and surfaces verdicts as structured metadata. The receipt model you describe then attaches the runtime safety verdict (along with policy hash, etc.) to the execution receipt, giving you layers 1 to 4 in a single audit trail.
Example shape on the proxy side:
from langchain_senthex import ChatSenthex
chat = ChatSenthex(provider="openai", model="gpt-4o-mini")
response = chat.invoke("...")
print(response.response_metadata["senthex"])
# {
# 'shield_status': 'pass',
# 'injection_score': 0.0,
# 'pii_found': 0,
# 'data_classification': 'PUBLIC',
# 'request_id': 'b5c654b4-...',
# ...
# }
That covers the input and output side. Your wrap_tool_call layer would still handle the action side. Together they cover the 5 layers without overlap.
Disclosure: I built langchain-senthex (EU-hosted reverse proxy, GitHub - YohannSidot/langchain-senthex: LangChain provider for Senthex Proxy — EU-hosted AI firewall with 26 shields, EU AI Act Article 15 audit · GitHub). Curious if your framework-neutral profile spec has room for upstream verdict ingestion. That’s exactly the kind of interop point that would make multi-layer auditing actually work in practice rather than living in silos.
This is a useful distinction. I agree that wrap_tool_call only covers the action boundary and does not cover LLM input/output risk before a tool is invoked. The right extension point for the framework-neutral profile is probably not a Senthex-specific dependency, but a generic upstream-verdict ingestion envelope: provider, boundary, request_id, policy_hash, status, scores, classification, timestamp, and digest. A Senthex verdict could be one implementation of that envelope; local DLP, model-call middleware, or enterprise gateway verdicts should fit the same shape. That would let the execution receipt bind model-boundary safety evidence and tool-boundary execution evidence into one verifiable audit path.
Agreed vendor-neutral is the right call, and honestly the only one that makes the profile credible. A verdict envelope that Senthex, a local DLP, or an enterprise gateway can all emit is far more useful than any single dependency.
Two things I’d add from implementing this in practice, so the envelope stays verifiable and not just informative:
digest covers a canonical hash of the (optionally redacted) request/response the verdict was computed over, the receipt can later prove the scores correspond to the actual model round-trip not just that a verdict existed. Without that binding, the envelope is attestable but not verifiable.policy_hash against a named ruleset/shield-suite version, so a verdict from six months ago stays interpretable.Happy to contribute a concrete mapping from thelangchain-senthex response metadata to this envelope as one worked reference implementation — as an example of the shape, not a dependency. If useful, I can sketch the envelope schema (JSON) with these fields and open it as a separate discussion so it doesn’t derail this thread.