Start with the authority your agent actually needs.
Agentic workflows cross a line when they can act on systems rather than merely return text. The first question is therefore not “can the model call a tool?” but “which exact capability is necessary for this task?” Give the workflow the narrowest read, write, network, filesystem, or account permissions that let it produce useful work.
Separate environments and credentials. A development agent should not inherit production access. A workflow that prepares a change should not automatically deploy it. Use scoped service identities and server-side enforcement rather than relying on an instruction in a prompt to prevent a forbidden action.
Constrain tools with schemas and policy checks.
Define a small tool surface with explicit input types, allowed values, permission checks, and output shapes. Validate arguments before calling the underlying system. A model-produced tool call is a request for action, not authorization to act.
- Expose read-only operations before write operations.
- Limit resource IDs, paths, query scopes, and destinations with server-side allowlists.
- Set time, cost, recursion, concurrency, and retry budgets.
- Return structured tool results that clearly distinguish success, absence, and error.
- Log the proposed action, policy decision, actor, and result at an appropriate security level.
When the Tokenra route exposes a compatible tool-calling shape, verify the current provider behavior before enabling it. The API reference describes the basic request boundary; your application remains responsible for all execution controls.
Treat tool output and retrieved content as untrusted.
Documents, web pages, tickets, databases, and tool responses can contain text that attempts to redirect an agent. Keep untrusted content clearly separated from application instructions, and do not let it grant permissions, change policies, or select unrestricted tools.
Design the application so sensitive actions require explicit, structured data that comes from trusted configuration or an approved human decision. Sanitize outputs before putting them into a shell, query, URL, template, or downstream automation. The model should never be the sole security boundary for an external instruction.
Pause before actions that are difficult to reverse.
Build an approval step for changes to shared state, external communications, financial actions, production systems, access control, or data deletion. Present the planned operation, affected scope, source evidence, and expected outcome in a form a reviewer can evaluate. Record the approval separately from the model response.
For lower-risk actions, use simulation or dry-run modes. For repeated workflows, sample and audit completed runs, and make it easy to stop the workflow when behavior drifts. Error handling should end in a safe state rather than escalating permissions or retrying a destructive action.
Agentic workflow safety questions.
Can a prompt alone keep an agent safe?
No. Prompts can guide behavior, but permissions, validation, budgets, environment isolation, and approval rules must be enforced by the application.
Should every tool call need human approval?
Not necessarily. Match controls to impact. Read-only, bounded actions can often be automated; irreversible, high-impact, or broad-scope actions should require review.
How should I handle a tool error?
Return a structured error, avoid repeating unsafe side effects automatically, and allow the application or a human to decide the next step based on an explicit policy.