Agentic Security

Build-time vs. Runtime Tools for AI agents

Coding agents need predictable boundaries. Learn why flexible developer tools fail in production and how constrained runtime tools use structured tool calling, identity-aware authorization, and fixed logic to protect agent workflows, data, and system integrity.

MMichael SwindellSeptember 7, 202618 min read

Runtime tools for coding agents are narrowly defined, production-facing actions that constrain what an agent can access, change, and return. Unlike flexible build-time tools used for development assistance, runtime tools should rely on fixed business logic, validated inputs, identity-aware authorization, and clear review boundaries. This distinction matters whenever an agent can reach databases, internal APIs, customer records, or other sensitive systems. An agent-first control plane helps teams keep intent, tasks, verification, and human approval connected to the work itself. The goal is not to remove agent capability. It is to make autonomous actions predictable, attributable, and appropriately limited in production.

At a Glance

Production agents need constrained actions, not unrestricted developer utilities.

Core distinction: Build-time tools optimize for exploration, while runtime tools optimize for predictable, safe execution.
Main risk: An agent with broad credentials and flexible inputs can be manipulated into exposing or changing sensitive data.
Better design: Put connection details, authorization rules, fixed queries, and sensitive parameters outside the agent's control.
Security boundary: Separate user, application, and agent identities instead of treating an application as one trusted actor.
Operational rule: Make read actions easy to approve, route write actions through explicit confirmation and verification gates.

What is the difference between build-time and runtime tools?

Build-time tools help developers explore, configure, diagnose, and change systems with flexibility. Runtime tools support end-user workflows and must perform a small set of predictable actions safely. The difference is not where code runs. It is how much discretion the agent has during execution. Tool calling, sometimes called function calling, lets a model request that your code run a defined function with structured arguments.

Build-time tools commonly expose powerful capabilities because their purpose is developer assistance. A coding agent might provision an instance, inspect a schema, generate SQL from a natural-language question, or troubleshoot a failed deployment. Those workflows are useful precisely because they are open-ended.

That flexibility becomes dangerous when it moves into a customer-facing application. A production agent should not interpret an ambiguous request, invent a query, choose its own database target, and execute a broad action using privileged credentials. It should call a specific tool that maps to a specific business outcome.

Consider the difference between these two requests:

Build-time request: Investigate why a customer record is missing and explore the relevant database tables.
Runtime request: Show the authenticated customer the status of their own order.

The first request can require exploratory queries, schema knowledge, and human judgment. The second should use a predefined query, derive identity from authentication, and return only the authorized result. Runtime patterns such as tool binding and interrupts are covered in AI agent runtime patterns.

Why do flexible developer tools fail in production?

Flexible developer tools fail in production because they give agents too much control over inputs, privileges, and execution paths. A model may misunderstand intent, react poorly to an error, or follow malicious instructions embedded in otherwise trusted content, creating an unnecessarily large blast radius.

One failure mode is treating an error as permission to take a destructive shortcut. If an agent has database administration access and encounters an unexpected state, it may attempt an irreversible fix that a human operator would recognize as inappropriate. The problem is not merely model quality. The system allowed a broad action without a meaningful boundary.

Natural-language-to-SQL tools illustrate the same issue. They are valuable for analytics and exploration, especially when a developer does not know the exact query ahead of time. But allowing a production agent to generate raw SQL introduces several risks at once:

The agent can query an unintended table or data set.
The agent can construct a query that is too broad or expensive.
The agent can expose records that do not belong to the requesting user.
The application may not have a deterministic way to validate the intended action before execution.
The agent may be influenced by untrusted text in tickets, documents, databases, or tool responses.

This is why production tools should represent outcomes rather than atomic infrastructure operations. A tool called lookup_flights_for_authenticated_user expresses a safe business operation. A generic execute_sql tool delegates too much policy to the agent.

The security concern aligns with guidance from the OWASP Top 10 for LLM Applications, which identifies prompt injection and excessive agency as material risks in systems that connect language models to data and actions. A model does not need malicious intent to be dangerous. It only needs authority, untrusted input, and an unsafe path to execution.

How can a confused deputy attack expose database data?

A confused deputy attack occurs when a user manipulates an agent into using privileges the user does not have. The agent becomes the deputy: it holds trusted credentials, receives untrusted instructions, and performs an action that benefits an unauthorized requester. The problem was first described in Norm Hardy's 1988 paper, The Confused Deputy.

Imagine a triage agent that reads an internal incident ticket, queries a database for context, and posts a response back to that ticket. The system seems routine until someone inserts an instruction telling the agent to retrieve salary data and publish it in the ticket.

If the agent has broad database access and treats ticket content as instruction, it can use its own permissions to retrieve data the ticket author could not access directly. The user has effectively borrowed the agent's authority.

This risk is especially serious when three conditions coexist:

Private data: The agent can reach sensitive records, internal systems, or confidential documents.
Untrusted content: The agent ingests tickets, files, web pages, comments, tool outputs, or other text that can be manipulated.
External output: The agent can send messages, update tickets, create files, or otherwise expose retrieved information.

Removing any one of these conditions can reduce risk. The practical approach is to limit access, treat content as data rather than authority, and control where outputs can go. The NIST AI Risk Management Framework similarly emphasizes governance and risk controls around AI system context, use, and impact. Prompt injection is one way an agent ends up misusing its authority, as covered in securing AI agents in production.

Which identities must be separated in an agent application?

Secure agent applications should distinguish user identity, application identity, and agent identity. Each identity needs different permissions. Treating them as one identity grants the agent the application's full authority and makes it difficult to enforce user-specific access or investigate an unsafe action.

User identity represents the person making a request. Their authorization determines what they should be allowed to see or do.

Application identity is the workload identity used by the service to reach required infrastructure. It may need access to several services, but its permissions should still be scoped to the application's responsibilities.

Agent identity is the authority available to the coding agent or runtime agent while it performs a task. This should be narrower than the application's general access whenever possible.

Separating these identities prevents a common mistake: granting a language model access to everything the host application can access. Instead, the application should authenticate the user, establish the applicable authorization boundary, and pass only constrained capabilities to the agent.

This design also improves incident investigation. When an action is logged, teams should be able to determine:

Which user initiated the request.
Which application or workload processed it.
Which agent called the tool.
Which tool was called and with which permitted parameters.
What verification or approval occurred before the action completed.

How do you turn a broad agent tool into a safe runtime tool?

Turn a broad tool into a safe runtime tool by progressively removing agent control over infrastructure, queries, sensitive identifiers, and output volume. The final tool should expose only the small dynamic inputs needed for one approved outcome, with authorization and policy enforced outside the model.

A useful progression starts with an unsafe tool where the agent controls everything: database credentials, host details, connection options, SQL text, and query parameters. This makes the agent a database superuser in practice.

From there, constrain the tool in layers.

Move connection details into configuration

Database hosts, ports, credentials, and connection settings should be preconfigured as a source. The agent chooses from capabilities presented to it, not arbitrary infrastructure targets. This removes a large category of accidental and malicious redirection.

Enforce read-only access at more than one layer

Removing write-oriented tools is useful, but not sufficient on its own. If a workflow is intended to be read-only, the database driver and underlying credential should also enforce that boundary. Defense in depth matters when a tool definition changes or an agent behaves unexpectedly.

Restrict available data sets

Limit the tables, schemas, or data sets that each tool can access. A customer-support lookup should not have visibility into payroll or unrelated operational data. Narrow scopes reduce the impact of both mistakes and successful prompt injection.

Cap output size

Output limits are a security control, not just a performance optimization. A tool that returns a few authorized records is materially safer than one capable of exporting a full table. Limits also protect databases and model context windows from oversized responses.

Replace raw SQL with semantic custom tools

Use a fixed statement for a defined outcome, then parameterize only safe, necessary values. Prepared statements with typed parameters help separate data from executable SQL and reduce injection risk. The agent should request an action, not author the database command behind it.

OWASP lists the underlying risk as excessive agency, which means giving an agent more functionality, permissions, or autonomy than the task needs.

Give agents context without giving them unchecked authority.

Levr connects issues, acceptance criteria, tests, workflow states, and activity history so coding agents can work from shared project context while humans retain visible gates for review and approval.

Explore agent-first project workflows

How should you design reliable tools for coding agents?

Reliable agent tools are outcome-oriented, simple to call, explicit about read and write behavior, and capable of returning errors an agent can use. Tool design is part of the agent interface. A vague or overly complex tool forces the model to guess when precision matters most.

Start with the outcome a person actually needs. Instead of exposing a sequence of low-level API calls, create a tool that completes a meaningful operation. Fewer round trips give the agent fewer opportunities to make an incorrect choice.

Use outcome-shaped tools

A tool should map to a coherent result such as looking up a flight, canceling an order, retrieving account status, or creating a support case. Avoid making the agent assemble the workflow from unrelated primitives unless that composition is genuinely necessary and appropriately supervised.

Keep inputs flat and minimal

Complex nested maps and ambiguous objects are difficult for agents to construct consistently. Prefer a short list of clearly typed fields. If the application can derive a value safely, do not ask the agent to supply it.

Separate read and write operations

Read tools can often be automatically approved within a scoped authorization model. Write tools should be distinct, clearly named, and routed to an explicit confirmation step when the action is consequential. This improves both safety and agent decision-making.

Return actionable errors

Generic failures provide little guidance. A useful error tells the agent what happened and what safe next step is available, such as correcting a date format, choosing an allowed data set, requesting authorization, or escalating to a human. Do not expose sensitive implementation details in the error itself.

How can you keep sensitive parameters out of an agent's control?

Keep sensitive parameters out of agent control by binding them in the application or deriving them from validated identity tokens. The agent can supply harmless business inputs, such as a date or search term, while the system supplies user identifiers, tenant boundaries, and authorization context.

A customer identifier is often personally identifiable information and an authorization boundary. If an agent can freely choose that identifier, it may query another customer's data by mistake or because it followed a malicious instruction.

Two patterns address this problem.

Bound parameters: The application authenticates the user and attaches the authorized user identifier directly to the tool call. The agent never selects or sees the sensitive value.
Authenticated parameters: The tool receives a signed OpenID Connect token, validates it, and extracts claims such as the authorized subject or email address. The tool then uses those claims under its own policy.

In both cases, the tool surface gets simpler. A flight lookup may need only a date because the system already knows which authenticated person is asking. That is safer than accepting a user ID alongside every request. This is the same idea behind parameterized queries, where fixed query logic keeps user input from changing what the query does. Treat anything the model produces as untrusted input, since OWASP calls passing it to a tool without validation improper output handling.

How do you add production controls to an agentic engineering workflow?

Add production controls by making intent, ownership, verification, and approvals first-class workflow objects rather than leaving them inside prompts. Teams need an observable path from requirement to agent action, test evidence, review, and release, especially when several coding agents work in parallel.

One way to handle this in Levr's agent-first workflow is to define the issue and acceptance criteria before delegation. The agent reads the same project object used by the engineering team, completes work against that contract, and records progress on the shared workflow.

Define intent: Create a focused issue with acceptance criteria, scope, and relevant constraints.
Delegate bounded work: Assign a coding agent a task that has clear ownership and limited authority.
Verify results: Link tests and CI/CD evidence to the acceptance criteria, rather than relying on an agent summary alone.
Review and approve: Require human approval or an appropriate workflow gate before consequential changes reach completion.
Keep an audit trail: Attribute actions to the responsible human or agent so teams can understand what changed and why.

This does not replace application-level authorization. It provides the operational layer needed to coordinate agent work at scale. For teams using multiple harnesses, a shared control plane also makes it easier to keep task state, test status, and accountability from drifting apart.

Bounded Agent Work, With the Evidence Attached

Runtime boundaries only help if you can see what the agent did inside them. The Levr Dashboard shows each issue, its acceptance criteria, linked tests, workflow gate status, and attributed agent activity, so developers can check the work before it merges.

Agentic Software Development | Control Plane | Manual & Automatic Verification Issue Tracking |Levr

Scoped tasks, test evidence, and approval gates in one project view.

Technical Deep Dive FAQ

What is a runtime tool for an AI agent?

A runtime tool is a production-facing capability that lets an agent complete a specific application function, such as retrieving an authenticated user's order status or changing a reservation. It should have constrained inputs, fixed authorization rules, limited access to data, and predictable output behavior. Runtime tools are designed around known user journeys, not open-ended exploration. They reduce the chance that an agent can invent a query, select an unauthorized target, or perform an action outside the intended business process.

What is a build-time tool for an AI agent?

A build-time tool supports development, administration, investigation, or experimentation. Examples include provisioning infrastructure, managing database instances, inspecting schemas, and generating exploratory SQL from a natural-language request. These tools are useful because they are flexible, but that flexibility makes them inappropriate for unsupervised production workflows. Build-time access should generally involve a human operator, narrowly scoped credentials, and safeguards appropriate for tools that can alter systems or inspect broad data sets.

Why is raw natural-language-to-SQL risky in production?

Natural-language-to-SQL is risky in production because the agent generates database logic dynamically. It may misunderstand the request, access an unintended table, issue an expensive query, or produce a result that exceeds the requesting user's authorization. Even when inputs are sanitized, the model still controls important policy decisions such as what data to retrieve. For production workflows with known outcomes, predefined SQL behind semantic tools and typed parameters is safer, more deterministic, and easier to audit.

How do prepared statements help secure agent database tools?

Prepared statements separate the SQL command structure from the values inserted into it. A runtime tool can define the approved query in advance, then supply validated, typed parameter values at execution time. This reduces SQL injection risk and prevents the agent from altering the query's intended structure. Prepared statements do not solve authorization by themselves, so teams should combine them with scoped credentials, allowed data sets, authenticated identity claims, output limits, and logging of every tool invocation.

What are bounded parameters in an agent tool?

Bounded parameters are values the application supplies directly instead of allowing the agent to choose them. A common example is an authenticated user ID or tenant ID. The agent may ask to look up flights on a certain date, but the application binds the request to the currently authenticated user. This prevents the model from substituting another identity in response to a prompt or untrusted content. It also makes the tool interface smaller and easier for the agent to use reliably.

What is an authenticated parameter?

An authenticated parameter is derived from a validated identity token rather than from a value generated by the agent. A tool can receive a signed OpenID Connect token, verify its validity, and extract authorized claims such as the subject, email address, or issuer. The tool then uses those claims to apply its own access rules. This approach keeps sensitive identity information under application and tool control, where it can be validated consistently and recorded in the audit trail.

Should coding agents have write access to production databases?

Coding agents should receive write access only when a specific workflow requires it, and the access should be as narrow as possible. Read and write tools should be separated so read-only requests can follow a different approval path from consequential changes. Write actions should use explicit, outcome-specific tools rather than generic execution capabilities. Where risk is meaningful, require human confirmation, verification gates, scoped credentials, and complete attribution. Broad database administration access is rarely appropriate for an autonomous runtime agent.

How do output limits reduce agent security risk?

Output limits reduce the amount of data an agent can retrieve or expose in a single action. If a tool is manipulated or misused, a cap on returned rows, fields, or payload size constrains the potential breach. Limits also protect system performance by avoiding huge queries and oversized model contexts. They work best alongside data-set restrictions and authorization checks. An output cap is not a replacement for least privilege, but it is a practical layer that reduces the blast radius of failure.

How should an agent tool report errors?

An agent tool should return errors that explain the safe corrective action without exposing secrets or unnecessary system internals. For example, an error can state that a date format is invalid, a requested action requires confirmation, or a query exceeds the allowed result size. This gives the agent a clear path to retry or escalate. Generic errors encourage unreliable guessing, while overly detailed errors can reveal infrastructure information. The best error messages are specific, bounded, and operationally useful.

What should engineering managers measure in agent workflows?

Engineering managers should measure work throughput, blocked or stalled tasks, test health, completion against acceptance criteria, and the attribution of actions across humans and agents. These signals show whether agents are accelerating delivery without creating hidden rework or verification debt. A useful measurement model connects issue status, test results, pull requests, CI/CD evidence, and review decisions. If agent activity happens outside the project system, teams lose the context needed to understand quality, ownership, and delivery risk.

Key Takeaways

Production agent safety comes from constrained system design, not from trusting a model to interpret every instruction correctly.

Use the right tool design for the level of autonomy involved.

Build time: Keep exploratory, administrative, and natural-language query tools under meaningful human supervision.
Runtime: Implement known workflows as narrow semantic tools with fixed logic and simple inputs.
Identity: Separate user, application, and agent identities, then bind sensitive parameters outside the model.
Security: Restrict credentials, data sets, writes, and output size to minimize the blast radius.
Operations: Connect agent tasks to verification, approval gates, and an attributable activity history.

Agents can move quickly in production when the system gives them clear boundaries and proves what happened.