The challenge behind the engagement.
This service is for agent systems: a single assistant with tools, an orchestrator with sub-agents, or agents that call one another over open connections. We inventory every agent, tool, memory store, and model, marking where untrusted content enters the reasoning loop: retrieved documents, tool output, and other agents' messages. We threat model how an agent could be steered off task or misuse its tools, then give each agent its own identity with short-lived credentials, decide per tool whether it acts as itself or as the user, and lock down how it connects to outside tools. Tool permissions default to read-only, and we name the actions that always stop for a human. You receive the diagram set, tool permission matrix, approval runbook, and backlog with owners; no production access is needed.
For engineering leads and architects building agents on any orchestration framework or managed agent service, and for the CISOs asked to approve them for production. Engage before the first tool with write access is granted, or before a second agent or a third-party connector joins the system.
What we do.
What you can use.
Inventory agents, tools, and memory
We start from your architecture documents or prototype, the tool list with its current permissions, identity details, sample prompts, and memory layout, with read access to your code and configuration. We agree which agents and integrations are in scope and how autonomous each is meant to be. A staging environment is enough; we never need production.
Design identity, permissions, and approval gates
We give each agent its own identity with short-lived credentials and no shared or passed-through logins, using the identity options your platform already offers. We build the tool permission matrix with read-only defaults, enforce policy at the connection layer rather than in the prompt, and specify how a human gate stops payments, deletions, and production changes.
Hand over diagrams, matrix, and backlog
You receive the diagram set with trust zones, identity flows, and approval gates, the tool permission matrix, the credential lifecycle design, the approval and escalation runbook, and a threat model mapped to recognized agent-risk categories and the controls that address them. We walk the backlog with your engineers, then review the built system against the design and record where it differs.
Who it’s for.
When you need it.
- Product teams giving an assistant tools that read data or take actions on users' behalf
- Platforms adding a second agent, sub-agents, or an orchestrator coordinating several models
- Organizations connecting agents to outside tools and services through open, third-party integrations
- Regulated teams whose agents will touch CUI, PHI, or export-controlled data
- You are about to grant an agent its first tool with write or delete access
- A prototype worked and leadership wants it approved for production use
- A third-party tool connector or external agent is joining an existing system
- A security review asked how the agent is scoped, authenticated, and stopped
What the scope can include.
- 01
Inventory of agents, orchestrators, tools, memory stores, and models, with every point where untrusted content enters the reasoning loop
- 02
Threat model of goal hijacking, tool misuse, memory poisoning, and cascading failures between agents, mapped to recognized agent-risk categories
- 03
Agent identity design: one identity per agent, acting as itself or as the user per tool, short-lived credentials, and hardened connections to outside tools
- 04
Tool permission matrix by agent, tool, action, and data class, with read-only defaults, scoped credentials per tool, and rate and spend limits
- 05
Approval points for payments, deletion, outbound messages, and production changes, with the interrupt mechanism and how each approval is logged
- 06
Inter-agent trust: message authentication, schema validation, provenance tags, per-tenant memory isolation, and sandboxed code execution with no egress by default
What it typically costs.
One rate: $150/hour.
Every engagement is priced by the hours it takes at one flat rate, with scoping, the work, and the final deliverables included. Find the size closest to yours.
One AI assistant with a few tools that read data or take simple actions
About 40–64 hoursA lead agent directing several helper agents, with tools that can change records or send messages
About 80–120 hoursA multi-agent platform shared by several teams or products, handling regulated data
About 140–200 hours- Number of agents, tools, and memory stores to design for
- How many actions need a human approval step
- Outside tools and third-party connections joining the system
- Regulated data (defense, health, or export-controlled information) that needs control mapping
Ranges are planning estimates at $150/hour, not a quote. Your price is confirmed in writing after a scoping call, before any work begins.
What you take forward.
- Architecture diagram set: agents, trust zones, identity flows, and approval gates
- Tool permission matrix (agent by tool by action by data class) and agent credential lifecycle design
- Approval and escalation runbook plus a logging and detection specification for every tool call and its arguments
- Threat model mapped to recognized agent-risk categories, with an implementation backlog naming owners
Final coverage, deliverables, timing, and any retesting or implementation work are confirmed before the engagement begins.
Before we get started.
Does each agent need its own identity, or can it act as the user?
Usually both, decided per tool. When an agent reads a user's mailbox or files, it should act as that user so existing permissions apply. When it performs a system action, such as opening a ticket or running a deployment, it needs its own identity with its own scoped credentials so the action is attributable and revocable. We record the choice per tool in the permission matrix, along with credential lifetime and where the credential is stored. Industry standards for agent identity are still settling, so we design to the authorization rules the current protocols already support rather than wait for the drafts to finalize.
How do we stop one poisoned document or compromised agent from cascading through the system?
Three controls, each specific. Untrusted content, meaning retrieved documents, web pages, tool output, and other agents' messages, is tagged with provenance and never allowed to widen permissions; the connection layer enforces the allowlist regardless of what the model asks for. Actions with irreversible effect stop at a human gate that a prompt cannot bypass, because the gate sits outside the model. Memory is isolated per tenant and per agent so a poisoned entry cannot reach another conversation. We do not claim a guardrail prevents injection; we design so that a successful injection has nowhere to go, and the activity log shows where it was stopped.
- Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile (NIST SP 800-218A)
- AI Risk Management Framework
- Joint Guidance on Deploying AI Systems Securely
- AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems
- OWASP Top 10 for Agentic Applications for 2026
- Model Context Protocol Specification: Authorization
- Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (NIST SP 800-171 Rev. 3)