Tools & Execution Environment
Agents become useful when they can act: read files, call APIs and MCP servers, run code and move data. This layer gives AI agents governed tools and isolated runtimes, so every action stays inside a boundary you set.
What is this layer about
A model on its own can only produce text. The moment an agent can open a file, call a business API, run a script or push to a repository, it acts on real systems. This layer is where that action happens, and where it needs the most care.
Every tool an agent can reach should be registered, described by a schema, and granted on purpose. Connectors, Model Context Protocol servers and file transfers all sit behind that registry, so teams know exactly which capabilities exist and who may call them.
Code the agent writes or runs should never touch production directly. It runs in an isolated runtime with limited access to the network, files and secrets. Zapper Edge's Data transfer harness lives here, moving data between systems under the same boundaries.
What do we deliver
Tool registry and schemas
A single catalogue of approved tools, each with a typed schema, an owner and a permission scope, so agents only see and call what they have been granted.
MCP server management
Connect agents to Model Context Protocol servers through a controlled gateway, with approved servers, scoped access and a clear view of which agents use which capabilities.
API connectors
Governed connectors to business systems and third-party services, with authentication handled centrally so agents never hold long-lived credentials of their own.
Secure file and data transfer
Compliance-ready movement and transformation of files and data between systems, through the Data transfer harness, with residency rules respected and every transfer recorded.
Isolated code execution
Shell and Python run inside sandboxed runtimes with limited network, file and resource access, so generated code can be tried without putting production systems at risk.
Git and secrets handling
Agents work through branches and reviewed changes in Git, while secrets are injected only at call time, scoped to the task, and kept out of prompts and logs.
Technology stack
- Tool protocols
- Model Context Protocol (MCP)
- OpenAPI
- JSON Schema
- gRPC
- GraphQL
- Execution sandboxes
- Docker
- Kubernetes
- gVisor
- Firecracker
- WebAssembly (Wasmtime)
- Languages and runtimes
- Python
- Node.js
- Bash
- Jupyter kernels
- Secrets and identity
- HashiCorp Vault
- Azure Key Vault
- AWS Secrets Manager
- OAuth 2.0
- SPIFFE
- Files, data and source control
- SFTP
- S3-compatible object storage
- Azure Blob Storage
- Git
- Apache Airflow
These are the kinds of technologies this layer is typically built from; the choice of each stays with the customer.
Business outcome
Agents that can act without overreaching. Teams let agents work on real systems because each tool is approved, scoped and recorded. Capability grows while the reach of any single agent stays bounded.
Generated code stays out of production. Scripts and commands run in disposable sandboxes, so a faulty or unexpected action is contained and discarded instead of reaching live data or infrastructure.
Credentials never leave their vault. Secrets are issued per task and kept out of prompts, logs and model context, which reduces the chance of leakage and makes access easier to review.
Data moves with proof of where it went. Every file and data transfer follows residency and access rules and leaves a record, which supports compliance reviews without manual reconstruction.
Frequently asked questions
What does the Tools and Execution layer cover?
It covers everything an agent can do beyond generating text: calling APIs, reading and writing files, running code and moving data. The layer decides which of those actions are available, under what limits, and how each one is recorded.
How is an agent's tool access limited?
Each tool is approved and scoped to a task, so an agent only reaches what that job needs. Permissions, parameters and data boundaries are set by policy, and every call is logged for later review.
Why run generated code in a sandbox?
Code written by a model can be wrong or behave unexpectedly. A disposable sandbox contains the effects, keeps live systems and data out of reach, and is discarded after the run, so a mistake stays small.
How does this layer relate to the layers around it?
Agent Runtime and Orchestration decides which step to take next, while this layer carries out the action. Safety and Policy Controls set the rules it enforces, and Evaluation and Observability record what happened.
Questions about your AI rollout?
Talk to us about how the seven layers fit your models and data.