Give AI agents a job—and a boundary

An AI agent that can prepare a useful report may also be one connection away from changing a customer record or sending confidential material. The business question is therefore concrete: what authority does this particular task require, and where does that authority end?

For the October 5, 2026 issue, we turn to security and identity. Our view is that permission design deserves a place in the product specification before an agent reaches production. The evidence below comes from published security guidance; the proposed operating checks are TaylorVentureLab’s analysis, not claims about measured customer outcomes.

Start with the resource being protected

NIST’s Zero Trust Architecture, published in August 2020, describes an approach centered on users, assets, and resources. It rejects implicit trust based solely on network location or ownership and treats authentication and authorization as separate functions. [1]

For an agent, knowing which account is connected does not establish that every available action is appropriate. A founder may authorize research into prospective customers without authorizing changes to their records. Access to one project does not establish authority over another.

Our practical recommendation is to write a short mandate for each workflow: its owner, purpose, permitted resources, allowed actions, and stopping conditions. Make it specific enough that someone outside the implementation team can understand the boundary. “Help with sales” is difficult to audit. “Prepare a draft account brief from these approved records” gives the team something concrete to implement and evaluate.

This also helps product teams discuss value. Each additional permission should enable an identifiable customer benefit. Convenience for the developer is a weak reason to enlarge the consequences of an error.

Remove permissions the job does not need

OWASP’s 2025 guidance on excessive agency identifies three contributing problems: too much functionality, too many permissions, and too much autonomy. It recommends restricting tools and privileges and enforcing authorization in downstream systems instead of relying on the model to decide what is allowed. [2]

Consider a hypothetical procurement assistant preparing a supplier comparison. It needs selected specifications and prices. Authority to change payment details would serve a different job and introduce a different risk.

Our design preference is to separate preparation from consequential execution. The assistant can assemble a recommendation; a distinct operation can enforce whatever approval is required before a commitment is made. The interface should make that transition visible.

This is a useful lens for Fortress Shield discussions: ask where a mistaken instruction could become a real action. That is an evaluation principle, not a claim that a named product already implements or guarantees these protections.

Inspect the connections between systems

The Model Context Protocol’s Security Best Practices documentation describes risks at the boundary between an agent’s tools and connected services. It warns against token passthrough: accepting credentials without validating that they were issued for the MCP server, then forwarding them downstream. It also describes consent failures involving proxy servers and requires appropriate per-client consent protections. [3]

The implication for buyers is straightforward. A successful connection is only the beginning of the review. Ask the supplier to explain which identity each service sees, what permissions it receives, and how a user’s consent remains attached to the requesting client.

Request a demonstration with two ordinary test accounts. Can the supplier show that one account’s connection cannot quietly become the other account’s access? A diagram can explain the intended arrangement; observable behavior provides a different kind of evidence.

Avoid turning protocol adoption into a blanket security claim. An integration still depends on the implementation, configuration, and surrounding application.

Test the refusals and the shutdown

OWASP’s Authorization Cheat Sheet recommends denying access by default, validating permissions on every request, checking access on the server, and testing authorization logic. It also cautions that excessive logging can expose sensitive information. [4]

For an agent workflow, we propose a compact acceptance exercise:

• Request a legitimate action on an allowed resource.
• Request the same action on a resource belonging to another account.
• Attempt a write operation through a workflow intended only to read.
• Withdraw the relevant permission, then attempt another operation.
• Inspect the records of those decisions without exposing credentials or unnecessary private content.

These are proposed checks, not a complete certification program. They should be adapted to the actual system and supplemented where its risks demand it.

Set a clear expectation for withdrawal of access. Measure how long it takes to become effective across the workflow, including queued work. If that behavior is unknown, the team has an unanswered operational question.

Make the evidence useful to management

Our suggested management review fits on one page: the workflow’s business purpose, the authority granted, the evidence from allowed and denied requests, unresolved weaknesses, and the person responsible for remediation.

This creates a better conversation about expansion. A successful demonstration can justify further investigation; broader access should require evidence appropriate to the larger consequences. Track the work needed to handle exceptions alongside the time the assistant appears to save.

This week’s action is small: choose one connected agent, list its effective permissions, and run the acceptance exercise with its owner. Record what happened, especially where the observed behavior differs from the intended mandate. Give the team a precise improvement to make before adding another connection.