An AI agent should receive the smallest set of data, tools and permissions needed for one defined outcome. It should ask for approval before consequential actions, leave a useful record and stop safely when the situation leaves its boundaries. That is the practical difference between an agent that helps and an agent that merely has access.
The dangerous question is, “What can we connect?” The better question is, “What exact job can this system perform safely, and what must remain a human decision?”
My position: autonomy is not a feature by itself. Useful autonomy is a carefully sized operating envelope.
Start with the job, not the model
“Answer questions from approved documentation” is a job. “Improve customer service” is an ambition. “Create a WordPress draft from an approved brief” is a job. “Manage our website” is an invitation to discover the boundaries during an incident.
A deterministic workflow should remain deterministic when the rules are stable. A form can route a lead by territory without an agent. A tax calculation should use the authoritative rules engine. Reserve model judgment for work that benefits from interpretation: summarizing a long request, finding relevant knowledge, proposing a draft or selecting among approved actions.
The model can recommend. A policy layer should decide what is allowed. A person should approve actions whose impact exceeds the system’s authority.
The Agent Job Card
This is an original implementation framework, not a certification or vendor standard. Complete it before connecting production data.
| Field | Question | Example |
|---|---|---|
| Outcome | What single result is the agent responsible for? | Create a support-ticket summary for review. |
| Inputs | Which approved sources may it read? | Ticket text and published support articles—not the entire CRM. |
| Tools | Which exact operations may it call? | Search knowledge, create draft, attach source links. |
| Limits | What may it never do? | No refunds, account changes, bulk exports or user creation. |
| Approval | Which actions require which human? | Support lead approves any customer-facing reply. |
| Record | What must be logged without exposing secrets? | Requester, tool, affected record, approval ID, result and policy version. |
| Stop | How is access paused, revoked and recovered? | Disable integration credential, cancel queued work and restore the prior state. |
Do not write “authorized staff” when the real approver is known. Do not write “relevant data” when the collection can be named. Ambiguity in the card becomes discretionary power in production.
Raise the control as the action becomes harder to undo
Use four levels:
- Observe: search, read and summarize approved sources.
- Propose: prepare a draft, recommendation or change set without applying it.
- Act reversibly: create a draft record, add an internal tag or update a staging environment within limits.
- Act consequentially: publish, send externally, change permissions, issue money, delete data or modify production at scale.
Level four deserves an explicit preview and human approval. The preview should identify the exact action, affected records, material inputs and expiration of the approval. “Allow” is not meaningful if the reviewer cannot see what will happen.
OWASP’s AI Agent Security guidance recommends explicit approval for high-impact or irreversible actions and structured logging for high-risk decisions. It also recommends separating decision-making from execution for irreversible operations. [4]
MCP is a connection pattern, not a trust decision
The Model Context Protocol can give a host a standard way to discover and invoke tools. It does not make those tools safe. The July 28, 2026 MCP specification says users should explicitly consent to data access and tool operations, and warns that tool descriptions must be treated cautiously unless they come from a trusted server. [1]
For networked MCP systems, authorization is part of the architecture. The current specification requires audience-bound tokens and prohibits passing an inbound MCP token through to an upstream API. That matters because a token intended for one resource should not silently become a reusable master key. [2]
In plain language: use separate trust boundaries. Authenticate the user. Authorize the specific tool. Let the integration obtain its own appropriately scoped upstream credential. Validate the operation again at the business system.
WordPress: let the agent draft before it can publish
WordPress Application Passwords provide revocable, per-application credentials tied to a user account. WordPress stores them hashed, shows them once at creation and exposes usage metadata such as last-used time and IP. They are intended for API access, and the documentation says to use HTTPS. [3]
That does not automatically create least privilege. The integration inherits what its WordPress user can do. Create a dedicated account with the narrowest suitable role, one credential per integration and a documented owner. Rotate or revoke it when the job changes.
Illustrative WordPress workflow: an agent reads an approved brief and selected knowledge sources, uploads cleared media and creates a draft post. It cannot install plugins, edit users or publish. An editor sees a diff, source list and disclosure notes before approval.
Illustrative WooCommerce workflow: an agent can look up a product, draft a response about availability and prepare a cart for review. It cannot change prices, issue refunds or expose another customer’s order. Those actions remain behind deterministic checks and authorized staff.
Custom and edge applications need the same discipline
A non-WordPress stack is not inherently safer. Expose narrow business operations—such as create lead draft or request quote review—instead of raw database access. Validate inputs and outputs, enforce tenant boundaries, limit rate and spend, and make repeated calls idempotent where duplication would cause harm.
If a browser agent can click the same interface as a human, the server still needs authorization. Hiding a dangerous button is not a security control. Enforce permissions at the API and data layers.
An audit trail is a product feature
A useful record answers: who requested the work, which agent and policy ran, what tool was called, what resource changed, who approved it and whether it succeeded. Redact secrets and unnecessary personal data. Preserve enough context to reconstruct the event without storing every private prompt forever.
NIST’s Generative AI Profile is voluntary and designed to help organizations incorporate trustworthiness into the design, development, use and evaluation of generative AI systems. It is a governance reference, not a product badge. [5]
My prediction: the durable competitive advantage will not be maximum autonomy. It will be the ability to grant useful authority quickly, observe it clearly and withdraw it without drama.
A practical pre-production exercise
Write the Agent Job Card. Test one allowed action, one prohibited action and one ambiguous request. Confirm the agent refuses or escalates correctly. Revoke its credential and verify access stops. Simulate a failed action and confirm retry limits prevent duplicates. Restore the prior state. Then have someone outside the build team review the logs and explain what happened.
If that review cannot distinguish a proposal from an executed action, the system is not ready for more authority.
Sources
- Model Context Protocol specification, 2026-07-28 — user consent, data control and tool-safety principles.
- MCP Authorization Security Considerations, 2026-07-28 — token audience validation, storage, HTTPS, PKCE and token-passthrough prohibition.
- WordPress Developer Resources: Application Passwords — per-application credentials, HTTPS, revocation and usage metadata.
- OWASP Cheat Sheet Series: AI Agent Security — approvals, monitoring, audit trails and separation of decision from execution.
- NIST AI 600-1: Generative AI Profile — published July 26, 2024; page updated April 8, 2026.