Agents and Tools

Protecting tool payloads and cross-agent messages, bounding agent capability, and enforcing policy at graph edges rather than only at endpoints.

Once an AI system can invoke tools and hand work to other agents, data moves through paths that no perimeter control observes. A tool call is a function invocation inside a process that was already admitted. An agent handoff is a message between two components on the same network.

This page covers configuring those paths as governed boundaries.

Enforce at edges, not only at endpoints

The common integration mistake is to protect the entry point of an agent workflow and treat everything after it as internal. In a graph-structured workflow, that leaves most of the data movement ungoverned, the interesting transfers are the edges between nodes, not the request that started the run.

Configure enforcement at:

Every tool invocation carrying business data, in either direction.
Every agent-to-agent handoff carrying data or delegated authority.
Every callback or hook that receives model output and acts on it.
Every write to shared state that another node will read.

Where your orchestration framework exposes retriever, tool, memory, and callback primitives, those are the integration points. Policy evaluation attaches to the primitive rather than to your workflow code, so a workflow change does not silently create an ungoverned edge.

Tool invocation

Two separate decisions per invocation, and it is worth keeping them separate:

May this principal invoke this tool at all? Evaluated against the agent's tool allowlist and current policy. Deny by default; add tools explicitly.

May this data cross this boundary? Evaluated against the payload. A tool the agent is permitted to call may still not receive a particular classification of data.

Configure both. An allowlist alone permits an authorized tool to receive anything the agent can read; payload policy alone permits any tool to be called as long as the data is benign.

Payload protection

Tool request and response payloads carrying business data are protected artifacts, not plain parameters. Each carries tenant scope, the invoking principal, the declared purpose, and a reference to the source artifacts it derives from.

Two rules to configure toward:

Metadata only across the tool boundary where possible. Pass artifact references rather than content, and let the tool resolve them under its own authorization. This keeps the number of places plaintext exists small and makes the tool's own access auditable. The MCP tool surface is built on this principle, bounded metadata, never raw content.
Signed responses for consequential actions. Where a tool response will drive an action with real effect, require the response to be signed by the tool's identity so the agent can verify origin rather than trusting the transport.

Bounding tool effect

Beyond authorization, bound what invocation can accomplish:

Call budgets per task or per window. An agent in a loop is a common failure mode, and a budget converts an unbounded loop into a bounded, alertable one.
Idempotency requirements for tools with side effects, so a retry or a replay does not repeat the effect.
Explicit confirmation for irreversible actions. Some operations should require a human decision regardless of what policy would permit, Lattix requires explicit confirmation for artifact registration and evidence recording for this reason.

Agent-to-agent handoff

A handoff transfers both data and authority. Both need to be explicit in the message.

Configure cross-agent messages to carry:

Sender identity, authenticated, not asserted in the payload.
Tenant scope, which the receiving agent validates rather than inherits.
The delegation chain, so the receiving agent's authority is bounded by the original principal's. See Workload Identity.
Declared purpose, validated against policy at the receiving end.
Artifact references rather than embedded content, wherever the receiving agent can resolve them independently.
Replay protection, so a captured handoff cannot be re-delivered to trigger the work again.

The receiving agent re-authorizes. It does not trust the sending agent's decision. This is the property that keeps a compromised or manipulated agent from being a universal authority for everything downstream of it: it can send whatever it likes, and the receiver still evaluates policy independently.

Authority narrows

Worth stating on its own because multi-agent workflows tend to violate it by accident: authority narrows along a chain, never widens. An agent receiving a handoff holds at most the intersection of its own attributes and those of the chain that reached it.

The accidental-escalation pattern to watch for: agent A cannot read a classification, so it delegates to agent B which can, and returns the result to A. Configure against this by ensuring the derived result inherits the classification of its inputs, so what comes back to A is still governed, and A still cannot read it.

MCP and protocol integration

For MCP specifically, the Lattix MCP server exposes the metadata-only control plane described in the MCP section. The properties relevant here:

Tenant-bound tokens, with the tenant preserved across every internal exchange.
Tokens are exchanged rather than forwarded, the MCP token is never passed to another service.
Tool inputs are bounded metadata. Plaintext content, credentials, keys, and raw artifact bytes are not valid tool inputs.

For agent-to-agent protocols, the same envelope model applies: identity, tenant, purpose, delegation chain, artifact references, replay protection.

For orchestration frameworks, integrate at the framework's own primitives so that policy travels with the graph structure rather than sitting in front of it.

Verification

An agent invoking a tool outside its allowlist is denied, with a legible reason.
An authorized tool call carrying an unauthorized data classification is denied on payload grounds.
A handoff to a second agent is re-authorized at the receiver, and a forged sender identity is rejected.
A captured handoff replayed a second time is rejected.
A delegated agent cannot access data the originating human principal cannot access.
A result derived from a classification the requesting agent cannot read remains inaccessible to that agent.
Exceeding a configured call budget stops the agent and raises an event.

Tests 5 and 6 together are the ones that catch accidental privilege escalation through delegation. They are worth running against your real workflow graph rather than a synthetic case.

Workload Identity, registering and scoping these principals.
Model Context Protocol, the MCP surface and its security properties.
Retrieval and Context, governing what reaches a context window.
Wrap an MCP tool call in a Lattix policy envelope, a worked integration spec.

On this page