If your operations team wants AI agents to quote, tender and book freight inside the TMS, the safe answer is not "no", it is "only by design". Give every agent its own identity and a short, written list of tools, keep anything that moves money or changes carrier bank details behind a person or a deterministic rule, treat every carrier email and document as untrusted input, and put one policy point in front of the tool calls that records every allow, deny and monitor decision.
This post walks that job end to end for the CTO of a logistics operator. If your concern is the software you ship to customers rather than the agents you run, the sibling post on an SBOM for every release at a logistics software company covers that job. The first two thirds work with whatever tools you already run. Safeguard enters at "How Safeguard does this", and the matching use-case page is Secure by Design Agentic AI. The company in the middle of the post is a composite, invented for illustration.
Key takeaways
- An agent that can call the TMS is a new user with system access. Most of the work is deciding what that user may do, not tuning the model.
- Secure by design, as CISA and its partners use it, means the builder carries the security burden by default: narrow tools, separate identities, safe defaults and a record you can show a customer.
- The risky actions in freight are few and easy to name: tendering or cancelling a load, accepting a rate above a threshold, changing carrier remit-to or bank details, releasing a shipment, and sending documents outside the company. Design those out of the agent's reach, or put a person or a fixed rule in front of them.
- Carrier emails, rate confirmations, PDFs and portal pages are untrusted. An agent that reads them can be steered by text hidden in them, which OWASP and NIST both describe.
- Safeguard capabilities covered here, all GA: MCP Guardrail (GA, documented as Guard), agent identity (GA), AI-BOM discovery (GA), AI agent discovery (GA), AI Gateway (GA), SCA and SBOM generation (GA), and policies and gates (GA).
- Guard policies decide each MCP tool call with allow, deny or monitor. CI gates use Block, Warn and Notify, with approvals handled through exceptions. They are separate mechanisms, and an agent programme needs both.
- Some things stay your job: deciding which actions an agent may take at all, the human approval step inside your own workflow, carrier vetting, and acting when the log shows something odd.
The situation
You are the CTO, or the most senior technology leader, at a logistics operator. That might be an asset-based carrier, a freight brokerage, a third-party logistics provider or a mix of all three. The transportation management system is the centre of the business: loads, lanes, carriers, rates, tenders, appointments, proof of delivery, invoices and settlements all live there or flow through it.
The trigger is usually a request from operations that sounds reasonable. The brokerage desk wants an agent that reads inbound load requests, finds capacity, and tenders the load to a carrier in the TMS. The carrier relations team wants an agent that answers "where is my truck" emails. Finance wants an agent that matches carrier invoices to rate confirmations and flags accessorial charges. A vendor has offered an MCP server for the TMS that "lets any agent book freight". A developer has already wired a coding agent to a staging copy of the TMS API.
Each request saves real time. Together they mean software will soon commit money, move goods and change who gets paid, and nobody has one list of which agent can call which TMS action with whose credentials.
A bad week looks like this. A booking agent reads a carrier email that contains instructions aimed at the agent rather than the dispatcher, and tenders a high-value load to a carrier the team has never used. Or an agent with broad API access updates a carrier's remit-to details because a document told it the carrier "changed banks". Or a load board integration stops responding, the agent retries, and the same load is tendered three times. Then a shipper's security questionnaire asks how AI tools that touch its freight are governed and logged, and the honest answer is "per team".
Freight already has a fraud problem that agents can make faster. In August 2023 the US Department of Transportation's Office of Inspector General told Congress about concerns over freight fraud, including stolen loads, brokerage fraud schemes and double brokering, where a load is passed on to another carrier without the original broker's or shipper's knowledge. An agent that can find carriers and tender loads at machine speed, with no check on whether the carrier is who it claims to be, turns one bad email into many bad bookings.
What you want: agents that do real work in the TMS, a default design safe enough that teams use it, and one record that answers a shipper, an auditor or your board.
The rules and standards behind it
There is no single US rule titled "secure your freight agents". There is a clear set of primary sources that define good practice for building and running AI agents, and those are what a customer, an insurer or an auditor will reach for. This section summarises them in plain words. It is not legal, regulatory or audit advice, so confirm how they apply to you with your own counsel and auditors.
CISA secure by design
CISA's Secure by Design work, set out with US and international partners in "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software", rests on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. The core idea is that the people who build a system should carry the security burden, rather than leaving customers to bolt on protection afterwards. Secure by default is the companion idea: the out-of-the-box configuration should already be the safe one.
For a logistics operator building agents, you are the builder, and the shippers whose freight the agents touch are the customers. The safe path must be the default path: an agent gets the smallest tool set that does its job, not the full TMS API with a note to "be careful".
Secure AI system development
The "Guidelines for Secure AI System Development", published by the UK National Cyber Security Centre and CISA with agencies from many countries on 27 November 2023, organise the work into four stages: secure design, secure development, secure deployment, and secure operation and maintenance. They ask builders to model threats to the system, to understand the supply chain of models and components, to protect infrastructure and models, and to monitor behaviour once the system is live. The guidelines say they follow a secure by default approach, and the operation and maintenance stage covers logging, monitoring and update management once the system is live.
OWASP on agents and excessive agency
The OWASP Top 10 for Large Language Model Applications (2025 edition) names the two risks that matter most for a booking agent. LLM01:2025 Prompt Injection covers instructions that reach the model through content it reads, not only through what the user types. LLM06:2025 Excessive Agency describes damage done when a model has too much functionality, too many permissions or too much autonomy. Its mitigations read like a design checklist for freight agents: limit the extensions an agent can call, limit what each extension can do, run actions in the context of the user rather than a shared high-privilege identity, and require human approval for high-impact actions.
OWASP's GenAI Security Project followed on 9 December 2025 with the OWASP Top 10 for Agentic Applications for 2026, a peer-reviewed list of the most critical risks for agents that plan, act and make decisions across workflows. Use it as a threat list when you design each agent, alongside the two LLM entries above.
The Model Context Protocol specification
Many agent stacks now reach business systems through MCP servers, so the MCP specification is a primary source in its own right. Its tools section (version 2025-11-25) says that, for trust and safety, there should always be a human in the loop with the ability to deny tool invocations. Servers must validate tool inputs, implement access controls, rate limit invocations and sanitise outputs. Clients should prompt for confirmation on sensitive operations, show tool inputs before calling, validate results before passing them to the model, set timeouts and log tool usage for audit. Its security best practices page names the attacks that apply to a TMS server: the confused deputy problem, token passthrough, session hijacking and poor scope design. It says token passthrough is "explicitly forbidden" because the server cannot tell clients apart and audit trails show the wrong identity.
Identity, tokens and zero trust
NIST SP 800-207, Zero Trust Architecture, sets the principle you apply to agents: no implicit trust because of where a request comes from, with authentication and authorisation decided per request to a resource. RFC 9700, the OAuth 2.0 Security Best Current Practice, says access tokens should carry the minimum privileges needed and be restricted to the resource they are meant for, and RFC 8707 defines the resource parameter that makes that restriction possible. For freight agents, that means one token per agent per system, scoped to what that agent does.
AI risk management and agent hijacking
The NIST AI Risk Management Framework (AI RMF 1.0, released 26 January 2023) organises AI risk work into Govern, Map, Measure and Manage, and NIST AI 600-1 (26 July 2024) is its generative AI profile. In January 2025 NIST's Center for AI Standards and Innovation described agent hijacking: instructions planted in data an agent ingests, causing it to take harmful actions. The damage an injected instruction can do is bounded by the tools the agent holds.
How teams do it today and where it breaks
Most logistics teams start in one of four places. Each one works for a while.
The shared integration user. The agent calls the TMS API with the same service account the EDI integration uses. It is quick, it hands the agent every action the integration has, and the TMS log shows "integration user" for everything, so nobody can tell later who tendered a load.
The prompt as policy. The system prompt says "never change bank details" and "never tender above the approved rate". This is a request to the model, not a control. A carrier email with the right wording can override it, and nothing outside the model checks whether the instruction held.
Approve everything. Every tool call pops up for a dispatcher to approve. Within a week dispatchers approve without reading, and the one call that matters gets the same click as the hundred that do not.
Block it at the firewall. A VP's pilot breaks, the team routes around the block from a laptop, and the agents become invisible.
What breaks in each case is the same thing: there is no place outside the model where a decision about each tool call is made and recorded, and no inventory that says which agent holds which access.
Illustrative scenario: a composite operator wiring agents into its TMS
This is a composite example, not a customer. Operator X is invented for this post. Its numbers are example inputs you can replace with your own, not results.
Operator X runs a freight brokerage and a small asset fleet in the United States. As example inputs, assume it moves around 2,000 loads a week, works with roughly 3,000 active carriers, and runs one cloud TMS with an API, a load board integration, an email inbox per desk, and a carrier onboarding portal. Operations has asked for five agents:
| Agent | What it should do | What it touches |
|---|---|---|
| Quote agent | Read load requests, price them from lane history | TMS read, rate tables read |
| Booking agent | Find capacity, tender loads to carriers | TMS read and tender, load board, carrier email |
| Track agent | Answer "where is my truck" emails | TMS read, telematics read, email send |
| Appointment agent | Book dock appointments at receivers | TMS read, receiver scheduling portals |
| Invoice agent | Match carrier invoices to rate confirmations | TMS read, invoices read, accounts payable flag |
The CTO's rule before go-live: own identity and tool list per agent, one policy point for every call, and the riskiest actions designed out rather than prompted out.
The team lists five actions no agent may complete alone: tendering above a set rate or to a carrier not approved for the lane, cancelling a tender, changing carrier remit-to details, releasing freight to another carrier, and sending shipment documents outside approved domains. For the booking agent, "tender" becomes two steps: the agent drafts a tender in a pending state, and a dispatcher or a deterministic rule in the TMS commits it.
The rest of this post follows Operator X through that work, first with any tools, then with Safeguard.
Step by step: designing freight agents securely
These steps work with or without Safeguard. Each one ends with something you can write down and show a customer.
1. Write the agent register
Before any agent touches production, list it. One row per agent, owned by a named person.
| Field | Example (Operator X, booking agent) |
|---|---|
| Agent name and purpose | Booking agent: tender loads to approved carriers |
| Business owner | Brokerage desk lead |
| Technical owner | Platform engineering |
| Model and provider | The model your team chose, and where it runs |
| Identity it runs as | A dedicated service identity, not a shared integration user |
| Systems it reaches | TMS, load board, desk inbox |
| Tools it may call | Listed by name, see step 2 |
| Untrusted inputs it reads | Carrier emails, rate confirmations, load board posts |
| Actions behind a person or rule | Tender commit, cancel, rate above threshold |
| Log location and retention | Where tool calls are recorded and for how long |
| Kill switch | Who can stop it, and how |
If you cannot fill in a row, the agent is not ready. You cannot govern an agent you have not listed.
2. Tier every TMS action by blast radius
Split the TMS API, or the MCP server in front of it, into tiers. The tier decides the default control.
| Tier | Example freight actions | Default control |
|---|---|---|
| Read | Get load, get carrier profile, get tracking status, search lanes | Allow, with output limits on bulk reads |
| Reversible write | Add a note, draft a tender, propose an appointment | Allow for the named agent, logged |
| Committing write | Commit a tender, accept a rate, book a dock appointment | A person or a deterministic rule commits; agent drafts |
| Money and identity | Change remit-to or bank details, approve payment, create a carrier | Never callable by an agent |
| Outbound data | Email documents, share BOLs or customs data externally | Allow only to approved domains, logged |
The point of the table is to make "never callable" a design fact. If no agent's tool list contains the action, no injected instruction can make the agent take it. For a longer list of ways to shrink what each server exposes, see MCP server permissions: a practical checklist for reducing blast radius.
3. Give each agent its own identity and scoped tokens
One agent, one identity, one token per system it reaches. Use the scopes your TMS and email platform support to grant only what the tool list needs. Where your MCP servers support OAuth, bind each token to the server it was issued for, as RFC 8707 describes, and never let one server pass a client's token through to another system. In the TMS audit log, the agent's identity should appear on every action it takes, so a person reviewing a tender can tell it came from an agent. The pattern is set out in more detail in scoped credentials per MCP server.
4. Treat everything the agent reads as untrusted
Carrier emails, attachments, rate confirmation PDFs, load board posts, receiver portal pages and web search results can all carry text aimed at the agent. This is indirect prompt injection, explained in direct vs indirect prompt injection. Design for it:
- Keep the agent that reads untrusted content away from the tools that commit. The track agent reads carrier email; it does not tender.
- Pass structured fields, not raw documents, to the agent that commits. Extract the rate, the MC or DOT number and the load ID with a parser, then hand those values on.
- Check facts against systems of record, not against the document. A carrier's bank details come from your vetted carrier record, never from an email.
- Put filters in front of tool calls that look for injection phrasing, oversized inputs and malformed encoding, and accept that filters catch some attacks, not all. The tool list is the control that holds when the filter misses.
5. Put one policy point in front of tool calls
A policy point is a gateway or proxy between agents and the MCP servers or APIs they call. For each call it decides allow, deny or log for review, based on the agent, the tool and the input. Unlike the prompt, it applies the same rule to every agent, holds when the model is fooled, and records every decision.
Start new rules in a log-only mode, look at what would have been denied, then switch the rules that hold up to deny.
6. Put hard limits on volume and value
Agents fail fast. Add limits a person would never hit:
- A rate limit per agent per tool, for example a cap on tender drafts per minute.
- A value ceiling per action, enforced in the TMS, not in the prompt.
- Idempotency keys on tender and appointment calls, so a retry cannot create a duplicate booking.
- A daily total per agent that pages a person when crossed.
7. Make the human step meaningful
Approval prompts work when they are rare and clear. Reserve them for the committing tier, and show the dispatcher carrier, lane, rate against the lane benchmark and whether the carrier is approved for this lane. If dispatchers approve more than a handful of agent actions an hour, the tiers are wrong.
8. Watch the supply chain of the agent itself
An agent ships with an SDK, a framework, MCP server packages and prompt templates. Keep an SBOM for each agent service, gate releases on known exploitable vulnerabilities, pin MCP server versions, and review a server's tool list and descriptions when they change, because that changes what the agent can do.
9. Log, review and rehearse
Record every tool call with the agent, tool, decision, matched rule and time, and review denials weekly. Rehearse the bad day: block one agent mid-shift and confirm the desk can carry on by hand. Plant instructions in a test carrier email and check that the tool list, not the model's good behaviour, stops the harm.
A same-day checklist
- Every agent is in the register with two named owners.
- No agent runs as a shared integration user.
- Remit-to, bank detail and carrier creation actions are on no agent's tool list.
- Tender commits need a person or a deterministic rule.
- Agents that read carrier email cannot commit.
- One policy point sees every tool call and logs every decision.
- Rate limits and value ceilings live outside the model.
- Each agent service has an SBOM and a release gate.
- Someone on call can stop any agent within minutes, and has practised it.
Which TMS actions should an agent never take alone?
Anything that moves money, changes who gets paid, or commits freight to a carrier you have not vetted. Remit-to changes, carrier creation and payment approval belong on no agent's tool list; tender commits, cancellations and freight releases can be drafted by an agent and committed by a person or a TMS rule.
What does secure by design mean for an agent we build versus one we buy?
For an agent you build, you own the whole list above. For an agent or MCP server you buy, CISA's principles frame the conversation: the vendor should carry the security burden by default and say openly how. Get the answers in writing (the FAQ below lists the questions), then put your own policy point in front of their server anyway, because you need your own record.
How do we prove control to shippers and auditors?
Show the agent register, the tool policy in force and a sample of the decision log. Between them they answer the usual questionnaire items: who can access the shipper's data, how changes are approved, and how activity is logged.
How Safeguard does this
Here is the same job in Safeguard. Each step links the docs page that describes it; screens and commands appear only where the docs show them, and the commands were not run for this post.
1. Find the AI already in your code and on your engineers' machines
AI-BOM discovery (GA) builds an inventory of AI assets across connected repositories, cloud accounts and SaaS integrations. In code it picks up imports of AI SDKs, prompt templates, notebooks, model weight files and MCP server configuration, and it records agent definitions as agents. For Operator X that means the booking agent's service, the vendor TMS server's config and the prototype a developer built all show up in one AI bill of materials. See AI-BOM Discovery.
AI agent discovery (GA) covers the coding agents your engineers run while they build these agents. The Safeguard CLI and Desktop app report, per device and person, which supported coding agents are installed, what each may do, which MCP servers each connects to and which tools it used. Credential values, file contents and tool output are never read. An administrator turns it on for the organisation, and each person allows it on their own computer, in the CLI with:
safeguard aidr collect on
The results appear under Assets › Inventory › Asset discovery. For a CTO, this answers "which of our engineers' agents can reach the staging TMS today". See AI agent discovery.
2. Register each TMS server and each agent in Guard
MCP Guardrail (GA), documented as Guard, keeps an inventory of MCP servers and agents as records you create. Servers are registered explicitly with a name, upstream URL, transport and the credentials Guard uses to reach them. Guard then asks each active server for its tools on a schedule and stores the list, so when the TMS vendor adds a tool you see it. Agents are also registered explicitly, each with a name, description and metadata such as team and environment.
This is where agent identity (GA) becomes concrete: each Operator X agent is its own record with a status, running risk and anomaly scores, and request counts. Guard does not scan your network for servers or agents; your agent register is the input. See Servers & Agents.
3. Route each agent through its own proxy URL
For MCP servers you do not control, such as a vendor's TMS server, Guard runs as a self-hosted reverse proxy in front of them. You point each agent at a proxy URL instead of the upstream server. A proxy URL binds a slug to one registered server, and optionally to one registered agent and one policy. Calls through it are attributed to that agent for policy targeting and audit.
So Operator X can expose one TMS server through a proxy URL for the quote agent, bound to a read-only policy, and another for the booking agent, bound to a policy that allows tender drafts. Each proxy request carries an organisation-scoped API key, and Guard reaches the upstream server with its own stored credentials, so the agent's key is not passed through. A denied call returns a normal JSON-RPC error with the rule's reason. See Guard Proxy Deployment.
4. Write the tool policy: allow, deny or monitor
A Guard policy is an ordered list of rules authored in your Safeguard workspace. Each rule can match on the MCP method, on the tool name with glob wildcards, and on the calling agent's ID, and resolves to one of three actions: allow, deny or monitor. The first matching rule wins, by priority. A request that matches no rule falls through to monitor, so new traffic is visible rather than silently allowed. Changes reach running proxies without a redeploy.
Rules can also carry input filters (block a pattern, cap input length, reject bad encoding, check for known injection and jailbreak phrasing), output filters (mask common PII, redact named columns, cap rows, mask by pattern) and a rate limit. Here is how Operator X might lay out its booking agent policy. The tool names are invented for the example.
| Rule (highest priority first) | Matches | Action | Extras |
|---|---|---|---|
| No payment or carrier identity changes | tools named like tms_update_remit*, tms_create_carrier*, any agent | deny | Deny reason shown to the agent |
| Booking agent drafts tenders | tms_draft_tender*, booking agent only | allow | Injection check and input length cap; rate limit per minute |
| Tender cancel and commit | tms_cancel*, tms_commit*, any agent | deny | Committed by dispatchers in the TMS |
| Carrier and load reads | tms_get_, tms_search_ | allow | Row cap and column redaction on bulk results |
| New tools from the vendor | everything else | monitor | Review before writing a rule |
The same mechanism is walked through for a whole enterprise rollout in securing MCP servers when every team connects agents to internal tools. Notice what is doing the work. The deny rules hold whether or not the model was fooled. The monitor fallback means a tool the vendor adds next month shows up in the log before anyone relies on it. See Guard Policies.
5. Stop an agent fast when something looks wrong
An agent record can be blocked, unblocked or quarantined directly. A blocked agent is rejected before policy is evaluated, whatever the rules say. A proxy URL can also be revoked to cut off one integration without touching others that share the server. The docs note that slug lookups are cached for up to five minutes, so build that window into your incident plan rather than assuming revocation is instant. This is the kill switch from the agent register, with a name attached. See Servers & Agents and Guard Proxy Deployment.
6. Keep the decision log
Every request Guard evaluates goes to an append-only audit trail: agent, server, tool, action, matching rule and reason, risk, jailbreak and anomaly scores, and any PII detected or fields redacted. Blocked calls are recorded too. On a self-hosted proxy deployment the default retention is 90 days, so if your customer contracts or audit plan need longer, export the events to your own log store on a schedule. See Audit Trail & Alerts.
7. Watch the model traffic itself
The policy point above governs tool calls. The AI Gateway (GA) governs the conversation with the model: it checks prompts for direct and indirect prompt injection, including content that arrived from tools or retrieval, checks for jailbreak patterns, and checks responses for PII leaving in the output. Monitor mode is the default: it records a guardrail event per decision and passes traffic through unchanged. Enforce mode, which redacts or blocks, is turned on per tenant. It fails open by default, so a gateway problem never stops your desks, and raw prompt and response text is never stored. Monitor mode on Operator X's booking and track agents shows how often carrier content carries instructions before anyone enforces. See AI Gateway.
8. Gate the agent's own software supply chain
The agent services are applications. SCA (GA) and SBOM generation (GA) cover their dependencies, including AI SDKs and MCP server packages, and policies and gates (GA) decide what can ship. Each policy has an Action: Block fails the gate, Warn passes it with a warning that names the policy, and Notify passes it and sends a notification. When a team needs to ship despite a failing policy, it requests an exception with a business justification and an expiry, an approver decides, and the decision is recorded. In CI, the docs show this command to fail a job on a gate:
safeguard ci scan --wait --fail-on-gate <gate>
See Policies & Gates and Policy outcomes and actions. A full walkthrough of gates in a pipeline is in guardrails and policy gates for a fintech CI pipeline.
9. Keep your own assistants on a short leash too
If your people connect an assistant to Safeguard's own MCP server, a new workspace starts with a small default set of read-only tools, everything that can change something stays off until an administrator enables it per tenant, and a failed lookup falls back to that small set rather than opening up. It is the same pattern you are asking of your freight agents. See Tool availability & gating.
Requirement, what Safeguard does, what you still own
| Requirement | What Safeguard does | What you still own |
|---|---|---|
| Know which agents and AI components exist | AI-BOM discovery in code and cloud; AI agent discovery on engineers' machines | The register's owners and purpose for each agent |
| One identity per agent | Agent records in Guard; proxy URLs bound to an agent | Identities and token scopes in the TMS and email systems |
| Least privilege per tool | Guard policy rules by agent, tool and method: allow, deny, monitor | Deciding the tiers and which actions exist at all |
| Untrusted input | Injection checks on tool inputs; AI Gateway checks on prompts and tool-supplied content | Splitting readers from committers; checking facts against records |
| Human or rule for committing actions | Deny rules keep commit tools away from agents | The approval step in your TMS workflow |
| Kill switch | Block or quarantine an agent; revoke a proxy URL | The on-call rota and the manual fallback |
| Evidence | Audit trail of every allow, deny and monitor decision | Long-term retention and review |
| Agent software supply chain | SCA, SBOMs, gates with Block, Warn and Notify and exceptions | Fixing what the gate finds |
What to measure
Use these as a checklist for your own programme. They are things to track, not results anyone has promised.
- Share of production agents listed in the register with both owners named.
- Number of agents whose tool list includes a money or identity action. The target is zero.
- Share of tool calls that pass through the policy point, by agent.
- Monitor decisions per week that still lack a rule, and how long they wait for one.
- Deny decisions per week by rule, and how many were real problems versus rules that need tuning.
- Time from "block this agent" to the agent being blocked, measured in a drill.
- Human approvals per dispatcher per hour for agent actions. If it climbs, the tiers need work.
- Days of decision log you can produce for a shipper on request.
What Safeguard does not do
- It does not decide what your agents are allowed to do. Guard enforces the policy you write. Choosing tiers, deciding that no agent may change remit-to details and designing the commit step in your TMS are your calls.
- It does not sweep your network for MCP servers or agents. Guard records are created explicitly. AI-BOM discovery and AI agent discovery find candidates in code and on engineers' computers; coding agents outside the documented list are not detected.
- It does not vet carriers. Checking that a carrier is who it says it is, and that bank details are genuine, stays with your carrier onboarding process and its data sources.
- It does not fire Guard alerts to your channels today. The docs say Guard's alert rule schema exists but rule creation and evaluation are not wired up yet. Review the audit trail yourself, or feed it into your own monitoring.
- It does not analyse tool descriptions for poisoning today. Review a server's tool list and descriptions yourself when they change; Guard's scheduled tool discovery tells you when the list changed.
- It does not catch every prompt injection. Injection checks reduce risk; they do not remove it. The tool list and the commit step are what hold when a check misses.
- It does not keep audit events forever by default. Self-hosted Guard keeps 90 days unless configured otherwise. Longer retention is your export.
Common mistakes
- Using the EDI service account for agents. It hands every agent every action and makes the audit log useless for telling agents apart.
- Writing policy in the system prompt. Instructions to the model are not controls. Put the rule where the model cannot overrule it.
- Letting the email reader commit. An agent that reads carrier email should not hold tender, cancel or payment tools.
- Approving everything. Constant prompts train dispatchers to click yes. Keep approvals for the committing tier.
- Turning on enforcement on day one. Start rules in monitor, read a week of decisions, then deny. Rules written blind break good workflows and get switched off.
FAQ
Is it safe to let an AI agent book freight in our TMS?
It can be, if the agent holds only the tools it needs, money and identity actions are out of its reach, committing actions go through a person or a rule, and every tool call passes a policy point that logs it. The model's good behaviour should not be the control.
What is excessive agency in an AI agent?
OWASP uses the term for harm caused when a model has more functionality, permissions or autonomy than its job needs. A booking agent that can also change carrier bank details has excessive agency, whether or not it ever uses it.
What does secure by design mean for AI agents?
The safe configuration is the default one: separate identities, a short tool list, dangerous actions designed out, untrusted input treated as untrusted, and logging on from day one.
Can we stop prompt injection in carrier emails completely?
No. You can limit what an injected instruction achieves: separate readers from committers, pass structured fields, check facts against your records, and add injection checks at the tool call and model layers.
Do we need MCP to apply these controls?
No. The design steps apply to any agent calling any API. MCP makes a policy point easier to place, because tool calls share one protocol and one place to inspect them, and the MCP specification spells out the security expectations.
What should we ask a vendor selling a TMS MCP server?
Which tools it exposes and whether you can disable them, how it authenticates, whether it passes your tokens to other systems, what it logs, how tool changes are announced, and how you would stop it in an emergency. Then put your own policy point in front of it.
How long should we keep agent tool call logs?
As long as your customer contracts, insurer and audit plan require. Decide that first, then make sure the log store can hold it. Ninety days is a common operational default, not a compliance answer.
Does Safeguard replace our TMS security settings?
No. TMS roles, API scopes and workflow approvals stay in the TMS. Safeguard adds the inventory, the tool call policy point, model traffic checks and supply chain gates around them.
The steps above keep agents from doing harm with the tools they hold. The agent services, MCP server packages and SDKs underneath them are still open source software with their own vulnerabilities, and the section below covers how to close those gaps without waiting for an upstream release.
Fix it without waiting for upstream
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.
3. Gold Registry: start from components that are already fixed
Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | Safeguard policies and gates in CI |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
See how Safeguard would help
The first demo shows Claude being connected to the Safeguard MCP server with OAuth, then choosing which tools Claude can use. The same habit applies to freight agents: decide the tool list first.
Click through it at your own pace, or open it full screen.
The second demo is a real Android session: work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. That is a human step reserved for actions that change something.
Click through it at your own pace, or open it full screen.
The third demo is a real CLI session. Asked to fix the lodash CVE in a repository, the CLI reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. A TMS agent should behave the same way.
Click through it at your own pace, or open it full screen.
Quick check
An agent that reads carrier emails also holds the tool to commit tenders. What is the simplest design fix?
Split the roles. Give the email-reading agent read tools only, and let a separate agent draft tenders from structured fields, with a person or a TMS rule committing them.
In a Guard policy, what happens to a tool call that matches no rule?
It falls through to monitor: the call proceeds and is flagged in the audit trail for review, rather than being silently allowed or blocked.
Sources
- CISA: Secure by Design
- CISA: Shifting the Balance of Cybersecurity Risk, Principles and Approaches for Secure by Design Software
- UK NCSC and partners: Guidelines for secure AI system development (27 November 2023)
- OWASP GenAI Security Project: LLM06:2025 Excessive Agency
- OWASP GenAI Security Project: LLM01:2025 Prompt Injection
- OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
- Model Context Protocol specification 2025-11-25: Tools
- Model Context Protocol specification 2025-11-25: Security Best Practices
- NIST SP 800-207, Zero Trust Architecture
- IETF RFC 9700, Best Current Practice for OAuth 2.0 Security
- IETF RFC 8707, Resource Indicators for OAuth 2.0
- NIST AI Risk Management Framework
- NIST AI 600-1, Generative AI Profile
- NIST CAISI: Technical Blog, Strengthening AI Agent Hijacking Evaluations
- US DOT Office of Inspector General: Letter to Congress on household goods moving and double-brokering fraud
- Safeguard: Secure by Design Agentic AI use case
- Safeguard docs: AI-BOM Discovery
- Safeguard docs: AI agent discovery
- Safeguard docs: Servers & Agents
- Safeguard docs: Guard Proxy Deployment
- Safeguard docs: Guard Policies
- Safeguard docs: Audit Trail & Alerts
- Safeguard docs: AI Gateway
- Safeguard docs: Policies & Gates
- Safeguard docs: Policy outcomes and actions
- Safeguard docs: Tool availability & gating
To try the flows in this post, download Safeguard from safeguard.sh/download and read the setup guides at docs.safeguard.sh.
Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.
