An agent investigating a security alert encounters a malicious email telling it to disable endpoint protection. The enterprise must prevent that action even if the model proposes it. The same agent should still be able to gather evidence and recommend a response.

Before delegating consequential work, CISOs, CTOs, and boards need to establish who controls that boundary. Identity establishes which agent is represented; authority determines what it may do under current conditions. I recommend retaining enterprise ownership of that authority, regardless of where an agent runs or which model it calls.

Cloud lock in now includes the authority to act

Google Cloud, AWS, and Azure offer credible identity and gateway capabilities. Choosing their managed services can be sensible. The longer-term question is whether the enterprise can change providers without rebuilding its agent identities, permissions, approval relationships, and audit history.

An application may be portable while the meaning of its permissions and the structure of its audit evidence remain tied to a provider. Identity federation and cross-cloud connectivity alone do not establish equivalent controls.

An enterprise control plane should maintain consistent enterprise permissions, approval requirements, and evidence across clouds and on premises. Where a destination cannot enforce a required control, restrict the workflow or use another execution path. Native cloud controls continue protecting their resources. Ownership requires control over policy, usable evidence, and the ability to replace suppliers, including the control-plane supplier itself.

Choose where credentials can be used

There are several legitimate designs. An agent runtime can use short-lived, bound workload credentials. A managed gateway can hold its tool credentials. Trusted infrastructure can also hold both workload and integration credentials outside the agent’s sandbox.

In that last pattern, the agent requests an operation. A trusted node identifies the workload, and an integration proxy checks current permission before applying the destination credential. The agent remains identifiable without possessing the credentials used on its behalf.

Keeping credentials outside the guest reduces extraction risk. The enforcing proxy must still deny operations unless current authority permits the specific action, target, and arguments. Its privileges and tenant boundaries need protection. SPIFFE supports workload identity and authentication; action permissions require separate enforcement. External credential custody moves identity proof into trusted infrastructure.

Every approach needs operation-level authorization. Permission to reach an endpoint-management API is broader than permission to isolate one approved host. Approval must bind to the actual action, target, and arguments within an explicit validity period and enforced use limit. Withdrawn authority must stop further use within a tested time bound.

Version the models and preserve the evidence

Consistent security policy does not guarantee consistent agent behavior. A hosted model update, changed prompt, or automatic fallback can alter the agent’s decisions without changing its application code.

The control plane should connect each run to an approved execution configuration. Pin model versions where supported, record the model actually used, and version the prompts, tools, settings, and routing rules that influence its behavior. Evaluate upgrades against task completion, security requirements, quality, and cost before promoting them.

Retained inputs, model responses, and tool observations support investigation and evidence replay without repeating production actions. Evaluation reruns can compare a replacement model against the same cases. Version pinning improves that comparison but does not guarantee identical generated output. Hosted model retirement can also limit future reruns.

Treat retained evidence as sensitive enterprise data: minimize collection, exclude credentials, restrict access, encrypt records, and enforce retention limits.

Resuming real work requires current authorization. Historical approval cannot authorize a new effect, and a lost response cannot establish that an action failed. If a provider accepted a containment request before a timeout, recovery must reconcile the outcome before repeating it.

Ask for proof before expanding autonomy

Leadership should expect concrete answers to four questions:

• What can a compromised agent access, and which credentials remain beyond its reach?

• How quickly does revocation stop a running agent, including during service outages?

• Can we reconstruct the model version, approval, dispatched action, and observed result?

• Can we change clouds or models while preserving authority and demonstrating the required behavior?

Start with one valuable workflow. Prove that permitted work succeeds and unauthorized actions fail. Test revocation and recovery, then demonstrate the same security requirements in a second environment before claiming portability.

These decisions affect both risk and the cost of expanding automation. A reusable authority model can reduce the need to redesign security for each application, while versioned execution and retained evidence make failures easier to investigate and upgrades easier to evaluate.

For the architecture, cloud comparisons, and verification checklist, read the full technical article: Securing AI Agents Starts with the Authority to Act.