WORKING MACHINES GUIDE
Secure AI agent actions across business applications
PUBLISHED AUGUST 29, 2026 / REVIEWED SEPTEMBER 2, 2026
Secure agent execution separates model reasoning from credential storage and policy enforcement. The model may propose or invoke an action, but a trusted runtime must validate the schema, connection identity, permissions, destination, and policy before contacting the provider. The result should be redacted, structured, and tied to an execution record that operators can inspect.
Credentials are not model context
An agent needs the ability to act, not direct access to OAuth tokens, refresh tokens, API keys, or provider secrets. Keep credentials in a dedicated connection store and represent them to the agent with safe connection identifiers.
Credential isolation limits accidental disclosure, but it does not anonymize action data. Inputs sent to a provider and results returned to the agent can still contain sensitive business information.
- Encrypt credential records at rest
- Redact authorization headers and secrets
- Expose connection labels rather than token values
- Rotate and revoke provider credentials
- Separate connections by environment and purpose
Enforce permissions at execution time
Prompt instructions are useful guidance but are not a security boundary. Permissions must be checked by the runtime for every action. Policies can restrict providers, action IDs, connection identities, and high-risk operations.
Start from deny-by-default for sensitive workloads. Research agents may receive read access, support agents may update tickets, and engineering agents may create issues without receiving production infrastructure credentials.
- Provider allow and block rules
- Action-level permissions
- Connection-level grants
- Provider-native OAuth scopes
- Human approval for irreversible actions
Guard the network and external content
Provider actions create outbound network requests. Validate URLs, redirects, and resolved addresses to prevent server-side request forgery. User-supplied download URLs require public-only validation even when a trusted provider instance is allowed on a private network.
External messages, documents, tickets, and webpages can contain instructions designed to manipulate the model. Treat retrieved content as data, preserve source attribution, and prevent it from changing runtime policy.
- Use guarded HTTP and WebSocket egress
- Block loopback, metadata, and reserved addresses
- Validate every redirect hop
- Keep private-network access explicit
- Isolate untrusted content from system instructions
Verify and audit real work
A successful HTTP response does not necessarily mean the business task completed correctly. Store the action identity, connection identity, validated input summary, status, timing, and redacted result. Link this record to the originating agent task.
For high-impact workflows, add domain-specific verification: confirm the issue exists, the email is a draft rather than sent, the CRM field changed to the intended value, or the deployment reached the expected environment.
- Structured success and error envelopes
- Correlation and execution identifiers
- Redacted run logs
- Side-effect verification
- Operator review and correction metrics
Primary references
The protocol and security guidance in this article is grounded in the following primary documentation.