5 posts tagged with "AI Architecture"

Most “AI app” demos collapse three different questions into one login button:

1. Can this person open the shell?
2. Which agents are they allowed to talk to?
3. Which knowledge are they allowed to see, download, or ground answers on?

In a real enterprise agent webapp, those are three different control planes. Treat them as one and you get either a security hole or a support nightmare.

Figure 1. SPA calling a web API. Authentication gets you a token; authorization still has to happen on the API. Source: Microsoft Learn: authentication flows and app scenarios.

An agent that answers from documents is only as trustworthy as the document permissions behind it.

Teams often lock the chat endpoint carefully, then leave library browse and citation PDF downloads open to anyone who can sign in. That is not a knowledge boundary. That is a second door with a nicer UI.

*Figure 1. Product capabilities belong as app roles on the API. Source: Microsoft Learn: add app roles.

Enterprise agent programs often start from a menu: models, tools, maybe a multi-agent diagram copied from a keynote. The catalog feels like progress. Users still do not know which job the system is supposed to finish.

Start from ranked use cases. Decide orchestrator versus single agent versus tools per job. Pilot decision quality and handoff clarity before you bet the platform on a topology that looked good in a slide.

Figure 1. Pilot the job the shell must serve. Agent topology follows the use case, not a catalog of models looking for work. Source: Microsoft Learn: authentication flows and app scenarios.

Users expect ChatGPT rules: close the tab, come back, the thread is still there. Platform agent services often have their own conversation store. Your shell is a third thing.

If those three disagree, you get untitled threads from the portal, agents that look "stopped" after refresh, and incomplete chats that vanish after a new sign-in.

Figure 1. The shell acquires tokens and calls APIs. Conversation durability is a separate design. Source: Microsoft Learn: authentication flows.

Browser shells tempt teams to over-trust the SPA. The chat UI looks like the product. The proxy in front of the agent backend is where authentication becomes authorization, where egress is constrained, and where dangerous payloads are allowlisted or dropped.

Treat the proxy as a security boundary. Choose Front Door, Application Gateway, or an equivalent pattern deliberately. Do not bolt TLS and authZ on later. Runtime mismatches between local and live proxies create false confidence. Reasoning and passthrough payloads need explicit allowlists. Security reviews should start at the proxy, not at the system prompt.

Figure 1. Harden the path from browser to agent APIs. Gateway controls are part of the product, not optional polish. Source: Microsoft Learn: API Management key concepts.