Give the agent its own identity
A prototype agent often runs on a single shared key or a broad service credential. That is fine for a demo and a liability in production: nobody can tell which action came from which agent, and one leaked credential exposes everything it can touch.
A production agent needs a scoped identity: a distinct credential per agent or agent type, access limited to the specific tools and data it uses, and short-lived tokens instead of long-lived secrets. That scoping is also what makes an audit trail meaningful, since an action can be traced back to the agent and the tool call that produced it.
- A distinct, scoped identity per agent or agent type
- Access limited to the specific tools and data it needs
- Short-lived credentials instead of long-lived keys sitting in code or chat
Plan for capacity limits before they become an outage
Agentic workflows call external model and tool APIs, and those APIs have rate and capacity limits. A workflow that has not been tested against those limits will eventually hit them, usually during the traffic spike that matters most rather than a quiet afternoon.
The fix is unglamorous: separate latency-sensitive calls from work that can run as a batch job, monitor for capacity errors directly, and alert on them before customers notice a stalled workflow instead of after.
Set spend guardrails, not just a budget report
A monthly invoice is not a control. By the time a spend report shows a problem, the cost is already incurred, and an agent that loops, retries on failure, or picks up a manipulated task can run up cost far faster than a person would notice.
Set hard spend caps at the project or workflow level with alerts at meaningful thresholds, and back that up with a rate limit on how often a given agent can call a model or tool. The cap should stop the spend, not just report it afterward.
Layer oversight around what the agent can act on
Google Cloud's reporting on agent governance and security identifies insufficient security for multi-system agent access as a commonly cited barrier to production deployment, and treats compliance visibility as a major factor in how organizations choose an AI platform.
No single control closes that gap. A workable approach layers several: secure-by-default handling of agent inputs and outputs to reduce prompt-injection risk, monitoring that exposes which tools and data an agent actually touched, and an explicit rule for which actions require human approval before they execute. None of that depends on the workflow performing well in a demo. It depends on the workflow staying inside its boundary when something goes wrong.
- Secure-by-default handling of agent inputs and outputs
- Monitoring that shows which tools and data an agent actually touched
- An explicit rule for which actions require human approval before they execute