In July 2026, Okta announced Agent Gateway. As Okta describes it, the gateway sits between AI agents and the systems they reach. For each tool call, it checks the agent's identity, the user behind it and the policies that apply, then issues a short-lived credential. Customers could request access to a research release, and as of October 2026 it was not generally available.

What I find useful is where the check happens. It is not a single decision at login. It is a decision about each action. That is a distinction worth making for anyone building agent-enabled software, whether or not they ever use a gateway like it.

An agent being able to connect to a system does not answer what it should be allowed to do there.

Reading a customer record, changing its owner, exporting the customer list and deleting the record are separate actions. I would want those differences represented in the product's permission model, not left for the agent to infer from a broad instruction.

Design the action boundary before the happy path

A compelling demonstration usually shows an agent completing a task. Before putting that workflow into real use, I would want to examine its boundaries.

Which records can it access? Which operations can it perform? Can it act across an entire organization, or only within an assigned task? Which actions need a person's approval?

Take a hypothetical sales assistant. It might need to read selected account notes and draft a follow-up message. That does not automatically justify permission to export every contact, change opportunity values or send messages without review.

The narrower workflow should shape the access it receives.

Separate suggestions from commitments

My starting point would be to sort what the agent can do into four groups:

  • Read information.
  • Produce a draft or recommendation.
  • Make a reversible internal change.
  • Take an external or consequential action.

These groups are a design aid, not a complete security framework. Their value is that they force a conversation about consequences.

A suggested meeting time is not the same as sending invitations. A proposed refund is not the same as issuing one. The user experience should make the step from proposal to execution visible.

Give approvals a defined scope

If an agent needs approval, I would show the person exactly what they are approving. For a message, that means the recipients and the complete content. For a bulk update, it means the affected records, the changes and any relevant limits.

If those details change afterward, my requirement would be to ask for fresh approval rather than treat the earlier confirmation as blanket authorization.

I would also not assume that a confirmation screen provides security. The underlying system still has to enforce the approved scope.

Plan for interruption and investigation

I would ask how an operator can pause the agent, revoke its access or stop a workflow that is going wrong.

I would also want a useful record of its actions: what it attempted, what was authorized, what changed and what failed.

That record needs careful handling too. Logging everything indiscriminately creates another place where sensitive information piles up. The aim is enough evidence to understand what happened, without making unrestricted data collection the default.

Make control part of the product

Agent governance is not only a concern for security teams. It raises interface and workflow questions too: how people grant authority, understand its scope, review actions and take permission back. Checking each tool call as it happens, the way Okta describes its gateway, is about governing what an agent does while it works, not only whether it can get in.

For me, the product lesson is straightforward. Do not design an agent as a powerful assistant first and add boundaries afterward. Design the useful task and its boundaries together. I hold my own coding agents to written rules for the same reason.

The question is not simply "Can this agent complete the work?" It is "Can we give it enough authority to be useful without granting authority the task does not require?"

If you are adding agents to your product and the permission model is still "whatever the login allows," email me.