Fort Wayne AI Agent Authorization Audit: NE Indiana 2026

A Fort Wayne IT director sent a screenshot last week of a Microsoft 365 Copilot session in which an agent — acting for a billing clerk who asked it to “summarize this morning's invoices” — pulled and re-summarized two years of historical billing for every patient on a multi-county roster. The agent was perfectly identified. Its non-human identity carried the right tags. The audit log showed exactly which session it inherited. None of that mattered. The agent was allowed to do what it did because the human clerk was allowed to do what it did — and the agent rode in on that authority without anyone narrowing the scope. The identity stack worked. The authorization stack did not exist.

According to VentureBeat's 2026-05-14 coverage of Cisco at RSAC 2026, this exact failure mode now has a name in the security press: agent authorization is broken, and the pattern that makes it worse is called authentication passing. The convenient default in nearly every SaaS agent integration that ships in 2026 is that the agent acts on behalf of the authenticated user and silently inherits the full authority surface of that user — not the narrow slice the user actually meant to delegate. The vendor solved the easy half of the problem. The customer is now holding the hard half.

For mid-market IT teams in Northeast Indiana — Auburn, Fort Wayne, and the Allen, DeKalb, Whitley, and Noble county corridors — this matters because most firms are now running Microsoft 365 Copilot, Salesforce Agentforce, a Claude Skill or two, and at least one home-grown agent under the same SSO. That is four agent personas with human-equivalent authority across ERP, EHR/PHI, billing, and customer records, and zero per-action enforcement between them and the resource. This piece prosecutes four claims and one audit pattern: that identity does not equal authorization, that authentication passing is the silent failure default, that the mid-market consequence is unbounded authority across regulated systems, and that the architectural answer is a buyer-owned authorization decision point. The pattern is the 6-Step NE Indiana Authorization Audit Playbook you can run inside 24 hours.

What is the difference between identity and authorization for AI agents?

Identity answers a question with a single tense and a single subject: who is this actor. It is the question solved by an identity provider, a service account, a non-human identity registry, or an mTLS certificate. When mid-market security teams spent the last eighteen months giving AI agents their own identities — the work covered in the 2026 agent IAM gap from RSAC — they were answering the identity question. They were not answering the authorization question. Authorization is a more granular and time-dependent question: given a verified identity, is this specific action, on this specific resource, at this specific moment, on behalf of this specific human's intent, allowed under policy. Identity is binary and durable. Authorization is conditional and transient.

The collapse between those two questions is what makes authentication passing dangerous. The agent inherits a session token issued to a human, and the downstream resource sees the human's full role authority behind the request. The resource cannot tell that the request came from an agent acting on a narrow user intent. It only knows the session is valid, the role is allowed, and the action is therefore allowed. The mental model the user had — just this morning, just my invoices — never crossed the wire. The role did. The role said all invoices, all time, all patients. The action was authorized at the role layer. Nothing was authorized at the intent layer, because the intent layer does not exist in most production stacks.

This is a different problem from credential theft. Zero-trust AI agents and credential isolation addresses an attacker stealing the credential the agent legitimately holds. Authorization addresses the agent legitimately holding the credential and using it for far more than the user wanted. It is also distinct from a confused-deputy attack — the confused-deputy audit matrix catalogs attacks where one principal manipulates another into acting with the wrong authority. Even in the absence of any attacker, the authentication-passing default produces unbounded authority. An attacker is a force multiplier on a problem you already had.

Why is authentication passing the silent default in 2026 SaaS agents?

Vendor incentives explain almost the entire pattern. When a vendor ships an agent integration into a product an enterprise already uses, the path of least integration friction is to let the agent act under the user's session. The user is already authenticated. The session is already valid. The vendor does not have to ship a new identity, a new permission grant flow, or a new consent prompt. They do not have to build an authorization decision point. They do not have to design per-action policy. The agent inherits the user, the user inherits the role, the role grants the action, and the action ships. This is fast for the vendor. It is fast for the user. It is invisible to security.

The pattern is also reinforced by the framing of SSO and federated identity. The same single-sign-on stack that an enterprise adopted in 2018 to reduce password sprawl is now the substrate on which AI agents inherit human session authority. That substrate was designed to make humans more productive across applications. It was not designed to constrain a non-human actor running thousands of decisions per second on behalf of a single human session. The Stanford HAI 2026 AI Index documents enterprise agent adoption now outpacing the security and governance discipline applied to those agents — exactly the gap authentication passing widens. The NIST Special Publication 800-207 on Zero Trust Architecture explicitly calls for per-request authorization decisions evaluated against the requesting principal's context — exactly the discipline that authentication passing violates by collapsing the request context into the durable role assignment of whichever human session the agent borrowed.

OWASP's Top 10 for LLM Applications places excessive agency at the top of the LLM-specific risk list for the same reason. When the agent has more authority than the user's specific intent requires, the agent is the attack surface. Prompt injection — covered for Northeast Indiana firms in Fort Wayne Microsoft Copilot prompt-injection risk — is dangerous precisely because it can manipulate the agent into exercising the authority the agent already has. Narrowing that authority is the upstream fix. Detecting the injection is downstream cleanup.

What does authentication passing look like in a Northeast Indiana mid-market stack?

The mid-market shape of this problem is concrete. Take a 120-employee professional services firm in Auburn or a 180-bed Parkview-tier regional health network in Allen County, or an I-69 corridor manufacturer in Whitley County running SAP-adjacent ERP. Each one almost certainly has Microsoft 365 with Copilot enabled tenant-wide. Each one is likely evaluating or already running Salesforce Agentforce for a customer-facing workflow. Each one has at least one Claude or custom agent active in a knowledge-base or document-review role. Each one has an internal IT-built RAG bot or a vendor-built one that pulls from the firm's data lake.

Under a single SSO tenant, those four agent personas inherit whichever human session invokes them. A nurse asking Copilot to “summarize this patient's recent visits” hands the agent the nurse's full authority surface — thousands of records, not the one chart the nurse is looking at. A sales rep asking Agentforce to “find similar accounts” hands the agent the rep's territory plus adjacent territories shared via collaboration permissions, often including pipeline data for accounts not yet assigned. An IT-built RAG bot serving “internal Q&A” frequently runs under a service account with tenant-wide read permissions across files, mail, and Teams, because that is what IT granted on day one so the bot could “answer anything.”

None of those agents is malicious. None of those agents is compromised. They are doing what authentication passing told them to do. The blast radius is structurally larger than the user intent because no system narrowed the authority between the inherited role and the specific action. For regulated Northeast Indiana firms — healthcare under HIPAA, financial advisors under SEC and Indiana Department of Insurance oversight, law firms under Indiana Rules of Professional Conduct — that blast radius is now a compliance liability and a breach notification trigger, not just a security observation. The Indiana Attorney General's Consumer Protection Division defines the notification obligations that follow when personal information is accessed beyond authorized scope, and the question of whether the agent's access was authorized is the precise question that the absence of an authorization decision point makes impossible to answer cleanly.

What is an authorization decision point and how does it sit between the agent and the resource?

An authorization decision point is a runtime component that sits in the request path between an agent and the resource it is trying to act on. Every action — read, write, send, delete, summarize, draft, schedule, transact — passes through the decision point before it reaches the target system. The decision point evaluates the action against a policy that considers four inputs: the verified identity of the agent, the verified identity of the human on whose behalf the agent is acting, the action being requested, and the context in which the request is being made. The output is a decision: allow, deny, or escalate for approval. The decision is written to an audit-grade log.

The pattern is not new. The architectural language is borrowed from zero-trust networking, where every request to a resource passes through a policy decision point before reaching the resource. What is new in the agent era is the requirement that the policy consider the narrowness of the human's intent, not just the breadth of the human's role. A nurse with full chart access who asks the agent for “this patient's recent visits” delegates a narrow intent to the agent. The agent's policy decision should reflect that narrowness — the agent should be allowed to read one chart, not thousands — even though the underlying role would allow far more. The authorization decision point is the place where that narrowing lives.

In the Cloud Radix architecture, the Secure AI Gateway is the authorization decision point. Every action emitted by every agent the firm runs — whether it is a vendor agent like Copilot or Agentforce, a Claude Skill, a custom-built agent, or a worker that the manager agent supervisor layer is overseeing — passes through the Gateway. The Gateway evaluates the action against the customer-owned policy and writes the decision to a log the customer controls. The NIST AI Risk Management Framework names this as the Manage function — controlling AI-system risk at the point of action with measurable, auditable decisions. The architecture is deliberately vendor-independent. The decision point lives in the customer's runtime, because the customer carries the breach-notification, contract, and regulatory exposure when the authorization decision was wrong. When a SaaS vendor updates their integration to broaden agent capabilities — which happens frequently and often without a visible change log — the Gateway-resident policy keeps narrowing the authority surface anyway, at the action site, every time.

The 6-Step NE Indiana Authorization Audit Playbook

The audit is designed for a mid-market IT team — typically a director and a couple of engineers — to run inside a single working day, with a follow-on instrumentation sprint that takes one to three weeks. Every step produces a written artifact that survives staff turnover and supports the audit trail an Indiana-domiciled regulated firm will need if a breach notification later becomes necessary.

Step 1: Enumerate every agent persona that inherits a human session

List every product, integration, plug-in, skill, custom build, and pilot that can act on a user's behalf. For each one, record the trigger surface (chat, email, calendar, file, browser extension), the SSO realm it inherits from, the human roles whose sessions it will accept, and the integration date. Tag the list against a four-row vertical model: Parkview-tier health system, regional law firm, I-69 corridor manufacturer, and home-services / dispatch operator — the verticals where authentication passing has the largest blast radius in Northeast Indiana. Most mid-market firms find six to twelve personas at this step. Many find that two or three were enabled by a department head without IT review, which is the same governance failure mode covered in the vibe-coded shadow AI S3 data leak playbook.

Step 2: Map each persona to the resource surface it can touch

For each persona on the list, document the resource surfaces it can read, write, send, delete, or transact against. Group surfaces into five buckets: ERP records (orders, line items, GL postings); EHR or PHI fields (charts, claims, prescriptions, billing); CRM and pipeline records (accounts, opportunities, contacts, deal history); file and content stores (SharePoint, OneDrive, Google Drive, network shares); communication and scheduling (email, chat, calendars, meeting transcripts). The mapping should record both theoretical surface — what the role grants — and observed surface — what the persona has actually touched in the last 90 days, pulled from existing audit logs. The gap between theoretical and observed is the unused authority that authentication passing keeps alive but the user never intended.

Step 3: Classify each action by scope expectation versus granted authority

For each persona-resource pair, classify the typical action by scope expectation — what the human asking the agent expects the agent to do — and compare that to the granted authority the agent inherited from the session. Use a four-row scope schema: one-record (a specific patient, a specific contract, a specific lead); batch (this morning's invoices, this week's tickets, this campaign's leads); schema-change (alter, drop, mass update, bulk delete); exfiltration-shaped (export, copy out, forward outside the tenant, render to a downloadable artifact). For each pair, write down where the scope expectation and the granted authority diverge. That divergence is the work the authorization decision point will do.

Step 4: Instrument the gap at the Gateway

Route every action from every persona through the Secure AI Gateway so the decision point can evaluate it. The instrumentation is a one-to-three-week sprint depending on the count of personas, and it does not require any change to the underlying SaaS vendors — the Gateway sits on the egress path of the agent's action, not inside the vendor's integration. The policy you write at this step should be authored against the scope-expectation schema from Step 3 rather than against the role surface from Step 2. The role surface is too broad. The scope expectation is the actual authority the user delegated.

Step 5: Ship per-action approval prompts for actions that exceed normal delegation

For actions that exceed the user's normal delegation pattern — not the user's maximum delegation, which is the legacy IAM concept — the Gateway issues a per-action approval prompt to the human. The approval surface should be lightweight (one click, one rejection, one reason) and tuned to the action's blast radius. The nurse summarizing one chart does not get prompted; the nurse's agent attempting to pull six thousand charts in one call does. The threshold is a customer decision, not a vendor default, and tuning it is the work of the second month of operation.

Step 6: Make the authorization decision log a first-class audit artifact

Every allow, deny, and escalate decision written by the Gateway should be retained as an audit-grade log — schema-versioned, integrity-protected, retention-period-aligned with HIPAA, GLBA, the Indiana AG's consumer-protection timelines, and any contract-of-engagement provisions the firm carries with regulated clients. The log is the single document a regulated firm produces when asked, after an incident, to demonstrate that the agent's access was authorized at the moment it occurred. Without the log, the firm cannot answer that question.

Why does this matter especially for Northeast Indiana mid-market firms?

Northeast Indiana's mid-market profile is a structural fit for the authorization gap to bite hard. Auburn, Fort Wayne, and the four-county corridor of Allen, DeKalb, Whitley, and Noble carry a high density of regulated firms — Parkview-tier health systems, regional law firms, multi-line insurance brokerages on Lima Road and Coliseum Boulevard, manufacturers running SAP-adjacent ERP along the I-69 corridor — most of which are below the staffing line where a dedicated AI security engineer is realistic. Those firms have nonetheless adopted Microsoft 365 Copilot and Salesforce Agentforce at roughly the same pace as Fortune 1000 enterprises, because both products ship as tenant-wide defaults their broader stack already includes.

The combination is the structural exposure: regulated industries, mid-market staffing, enterprise-grade agent surface area, no in-house authorization decision point. When an incident occurs and the breach notification obligation triggers under HIPAA, GLBA, or the Indiana AG's identity-theft prevention rules, the firm has to produce evidence of what the agent was authorized to do and how that authorization was evaluated. The firm that ran the 6-step audit has a Gateway decision log to point to. The firm that did not has only the SSO role assignment, which authorized everything the agent did regardless of intent. The first firm has a defensible posture. The second firm has a deposition risk.

The local angle also touches the regional MSP market. Mid-market firms in Northeast Indiana contract with regional MSPs for IT operations, and those contracts almost never include AI agent authorization scope today. The audit gives the customer a defensible spec to add to the MSP statement of work — persona-resource map, decision-point requirement, quarterly decision-log review — without a rip-and-replace.

Cloud Radix's regional authorization audit pilot

The Cloud Radix authorization audit pilot pairs a Northeast Indiana mid-market firm with the Secure AI Gateway and a Cloud Radix engineer for the 6-step playbook above. The pilot runs 30 to 60 days, depending on persona count, and produces three durable artifacts: the persona-resource map, the Gateway-resident authorization policy, and the schema for the audit-grade decision log integrated with the customer's existing SIEM. Firms that want to add the supervisor tier on top of the authorization layer can also pair the audit with the Cloud Radix AI Sub-Agents / C-Suite program so the manager agent has a clean policy substrate to govern. Get the pilot scoped at cloudradix.com/contact.

Frequently Asked Questions

Sources & Further Reading

• VentureBeat: venturebeat.com/security/enterprises-verify-agents-identity-cannot-control-authorization-cisco-rsac-2026 — Cisco at RSAC 2026: agent authorization is broken and authentication passing makes it worse (2026-05-14).
• NIST: nist.gov/itl/ai-risk-management-framework — AI Risk Management Framework; Manage function for action-site decisions (2023-01-26).
• NIST: csrc.nist.gov/publications/detail/sp/800-207/final — NIST Special Publication 800-207: Zero Trust Architecture; per-request authorization decisions (2020-08-11).
• OWASP GenAI Security Project: genai.owasp.org/llm-top-10 — OWASP Top 10 for LLM Applications 2025; excessive agency at the top of the list (2025-11-01).
• State of Indiana: in.gov/attorneygeneral/consumer-protection-division — Indiana Attorney General Consumer Protection Division; notification obligations when personal information is accessed beyond authorized scope (2026-01-01).
• Stanford HAI: hai.stanford.edu/ai-index/2026-ai-index-report — 2026 AI Index Report documenting enterprise agent adoption outpacing governance discipline (2026-04-01).