Your Agent Should Never See a Password

I run cloud operations at Itential. When I evaluate anything that touches production, my first question is never “what can it do?” It’s “where are the secrets?” Everything else about a system’s security posture follows from that answer.

Ask that of most agentic AI stacks and the answer is: everywhere. An API key in an environment variable the agent process reads. A token baked into a tool definition the model consumes. A secret in an MCP server config. Sometimes a credential pasted straight into a system prompt because it was the fastest way to make the demo work. Every one of those is a place a secret can leak – and a policy you now have to write, enforce, and audit by hand.

FlowAI was built on a different answer: the agent never holds, sees, or handles a credential – not at design time, not at runtime, not in its logs. This post is about what that means for critical production operations.

Credentials Are the Industry’s Number-One Way In

Here’s why this is the right thing to obsess over. Year after year, the major breach reports – Verizon’s Data Breach Investigations Report, IBM’s Cost of a Data Breach – put stolen and compromised credentials at or near the top of how attackers actually get in. It isn’t exotic malware or zero-days that dominate real incidents. It’s a valid credential in the wrong hands: consistently among the most common initial-access vectors, and among the slowest breaches to detect because a stolen key doesn’t look like an attack, it looks like a login.

Now hand that credential to an AI agent reasoning over untrusted input, and you’ve placed the industry’s number-one attack vector inside your most advanced actor.

That single fact shaped how Itential built agent security. Two decisions follow directly from it:

• The credential never enters the agent. If the top exploit is credential theft, the most effective control is to ensure there is no credential to steal where an attacker can reach it. The agent operates without ever holding, seeing, or transmitting a secret – so the prompt, the context, and the logs contain nothing worth taking.
• Authorization is role- and group-based, not baked into the agent. Every action an agent takes runs through Itential’s role- and group-based access controls – the same RBAC/GBAC model your team already uses for people and service accounts. An agent’s reach is defined by the roles and groups it is granted and enforced by the platform, not by anything the model can be talked into.

Together these turn the top attack path into a dead end: nothing to steal from the agent, and a hard, externally enforced ceiling on what any single agent can do.

Assume the Injection: The Credential Is the Blast Radius

Adopt the operating assumption every team running agents in production should: prompt injection is a concern. Agents consume a variety of inputs by design, and some of it will eventually be adversarial. Treating injection as preventable is optimism. Treating it as bounded is engineering.

So the real question isn’t “can the agent be manipulated?” It’s “what can a manipulated agent do?” If the agent holds credentials, the answer includes credential theft, and the incident is no longer scoped to the agent.

If the agent holds nothing, a successful injection is bounded by two things it cannot change: the tool set granted at design time, and the permissions of the systems those tools call.

What’s Actually in the Agent’s Context

During a FlowAgent run, the context contains exactly four things: the agent’s persona and instructions, the schemas of the tools it was granted, the conversation and session state, and the results of its tool calls. No credential appears anywhere in that list. The model cannot leak what it has never seen.

Here’s the mechanism. When the agent calls a tool, the execution engine resolves that call to the Integration Instance, Adapter, or Itential Gateway service behind it.

The credential lives on that component – in customer-controlled vaults or local secrets management – and the platform injects it at execution time, on the platform side of the boundary. The authenticated call happens there; only the result returns to the agent. The secret never crosses.

External tools follow the same path. MCP tools registered through the FlowMCP Gateway run under the same Gateway Manager RBAC and the same credential custody, on infrastructure the customer controls. Connecting an external AI system doesn’t open a second, weaker credential path. There is one path.

Scoping Is the Security Model

Because an agent’s reach is defined by the components it calls, the permissions on those components are the security model. Scope an agent to a read-only integration instance and it is a read-only agent – no matter how creatively it reasons or how successfully it is manipulated. Grant it change rights on one device class, and that is the entire universe of what it can touch.

This is the part I care about most from an operations seat: the least-privilege work your team has already done – role and group definitions, service-account scoping, integration credentials – didn’t become obsolete when agents arrived. It became the agent security model.

You’re not standing up a parallel permission scheme for AI. You’re pointing agents at the role- and group-based controls you already operate and audit.

The Model’s Own Key Follows the Same Rule

There’s one more credential in every agentic system that gets too little attention: the LLM provider API key. In a DIY stack it usually sits in an environment variable or config file, readable by anyone who can read the deployment.

On the Itential Platform, provider keys live in LLM Provider Profiles. An administrator saves the key once; from then on it is write-only – masked in the UI, never returned through the API, never included in exports or audit logs. Builders pick a named profile; they never see, copy, or manage the underlying key.

Every profile event – creation, edits, deletion, validation – is written to the audit trail. Credential custody applies to the model, not just the tools.

What This Looks Like in an Incident

Run the tabletop. An agent processing device output ingests a hostile payload and the model is influenced. On a stack where the agent holds secrets, incident response now includes rotating credentials across every system the agent could reach, plus forensics on what was exfiltrated before you noticed. On Itential, the compromised session can attempt only the tools it was granted, against systems whose permissions you set, with every reasoning step and tool call recorded in the FlowAgent Session trace. You read the trace, you see what was attempted, and you know with certainty that no secret left custody – because no secret was ever in the agent to leave.

That certainty is the point. Security reviews don’t run on assurances. They run on architectures where the bad outcome isn’t merely unlikely, it’s structurally unavailable.

Inspect It, Don’t Take My Word for It

The Itential Trust Center documents the full model: agent tool governance, credential handling, session-level audit, and the SOC 2 Type II reports behind it, available on request. Or request a demo and ask us to run an agent while you watch the session trace. Bring your hardest questions – they’re the ones this architecture was built for.