All Case Studies
Agentic AI
Case Study

Agentic AI Architecture and Controls

Architecture and controls for agentic AI in production: governed tool access, scoped identity, managed memory, runtime budgets, and approval boundaries designed as reusable foundations for federated adoption.

Bounded Agents: Delegation Security for Multi-Agent AI Systems (arXiv:2608.15888, author)
Agentic AI Architecture and Controls

Executive Outcome

01

Tool use got governed through explicit contracts, scoped permissions, and memory boundaries — invalid calls, unsafe inputs, and uncontrolled side effects all dropped.

02

High-stakes actions stayed controlled through approval paths, reversible-action policy, and runtime budgets, which kept the blast radius small when things did go wrong in production.

03

The control patterns got reused across teams, and the decision records and traces turned out to be genuinely useful for post-incident analysis, not just paperwork.

Engagement focus

Reusable architecture foundations and runtime controls for agentic AI, identity, tool governance, memory, runtime budgets, and approval boundaries designed for federated adoption.

What this covers
  • Tool governance with contracts, scoped identity, and side-effect classification
  • Memory hygiene, runtime budgets, and deterministic failure handling
  • Approval boundaries and decision traceability for high-impact actions

Context

The organization was moving from RAG-based patterns to agent-enabled workflows — AI that could invoke tools, touch operational systems, and take actions with real consequences. That shift changes the primary risk from bad content to bad actions, which is a different problem to solve for. The real question wasn't whether to allow agents; it was how to make them safe to run in a regulated, federated environment where several teams would build on the same foundations. That meant reusable control patterns for identity, tool governance, memory, and runtime — not guardrails bolted onto each use case separately.

The Challenge

  • 01Tool access was ungoverned. Agents could invoke tools outside their intended scope or trigger side effects with no classification or approval step in the way.
  • 02Identity and permissions were unclear — there was no model for scoping agent credentials, session identity, or least-privilege tool authorization.
  • 03Traceability was thin. No consistent record of why an action got selected, which permissions applied, or what checks actually ran.
  • 04Runaway execution was a real risk: looping, compounding errors, unbounded resource use, with no deterministic way to fail safely.
  • 05Memory hygiene didn't exist — uncontrolled growth, stale context, privacy exposure, and behavior that wasn't repeatable across sessions.
  • 06There was no delegation model, so the line between autonomous execution and human approval got drawn differently depending on who was building that day.

Approach

  • →Built a tool registry with strict contracts — schema, scope, idempotency, permission requirements, and side-effect classification per tool.
  • →Defined an identity and permission model: scoped credentials, session identities, least-privilege authorization, reusable across every agent implementation.
  • →Split actions into reversible and irreversible, and routed anything irreversible through an explicit approval step.
  • →Modeled memory explicitly — classes, retention rules, provenance — so ephemeral context stayed separate from durable records and sensitive data couldn't quietly persist.
  • →Added runtime controls: budget propagation, timeouts, rate limits, step ceilings, and deterministic failure handling with safe fallbacks.
  • →Stitched decision records end to end — intent, identity, permissions, memory operations, enforcement decisions, and outcomes, captured per tool call.
  • →Built it as reusable foundations from the start, so teams building agent-enabled workflows later weren't reinventing governance from zero.

Key Considerations

  • Stronger constraints cost speed and flexibility. We tuned that balance per risk tier rather than applying one setting everywhere.
  • Tool contracts need an owner and change discipline as the tools themselves evolve — this is ongoing maintenance, not a one-time design exercise.
  • Approval paths add latency, and we had to actively watch for bottlenecks and escalation fatigue.
  • Reusable patterns need governance for local adaptations, or drift creeps back in team by team.

Alternatives Considered

  • ✕Unbounded agents were never on the table — the operational and security risk in production is too high.
  • ✕Hardcoded workflows only — they can't handle unstructured input or the edge cases that show up once real users touch the system.
  • ✕Per-use-case guardrails don't scale in a federated org, and you end up with wildly inconsistent control coverage team to team.
Representative Artifacts
01Tool Registry and Contract Schema (scope, permissions, side-effects, idempotency)
02Identity and Permission Model (session identity, scopes, credential handling)
03Memory Model and Hygiene Policy (classes, retention, provenance, sensitive data rules)
04Action Policy Model (auto-approve vs. human review by risk tier)
05Runtime Budget and Execution Policy (timeouts, rate limits, step ceilings, cost caps)
06Decision Record Format (intent, identity, checks, enforcement, evidence, outcome)
07Trace Stitching Model (plan → tool call → outcome, including memory and permission traces)
08Connector Governance Checklist (credentials, scopes, rotation, approvals)
Acceptance Criteria

Agents cannot call tools outside permitted scope and contract constraints.

Irreversible actions trigger the defined approval path before execution.

Read access, reversible actions, and irreversible actions follow distinct control paths and approval expectations.

Every privileged or side-effecting tool call is executed through recorded policy checks and decision traces.

Recovery from tool errors demonstrated without runaway loops or budget overruns.

Agent identity scoped per session; tool permissions enforce least privilege with auditable authorization.

Memory writes follow hygiene and retention rules; no persistence of restricted data classes.

Runtime budgets, timeouts, and step ceilings enforced consistently with deterministic fallback paths.

Continue Exploring

Other Case Studies