Two different problems keep getting called "authorization for AI agents"- trying to separate them cleanly

I've been digging into agent-authorization failures and I think two genuinely different problems are getting flattened into one term, and I want people who actually build this to tell me if this split holds up. Problem A — actual authorization for agents. The agent (or the human it's acting for) requests access to a resource/action, and the system decides yes/no. This is the same job IAM/RBAC/ABAC does for humans and service accounts, just applied to a new principal type. Real gap here isn't the concept, it's adoption — most companies never route internal agent traffic through any gate at all, so even boring RBAC has nowhere to plug in. Problem B — post-authorization entity-correctness. Authorization already returned "allowed." Nothing about the access decision was wrong. But the specific record returned belongs to the wrong entity - e.g. a support AI legitimately allowed to answer account questions pulls the wrong linked account's balance, because the query resolved to the wrong subject, not because access was denied. This isn't an authorization failure by any strict definition — the gate did its job. It's a data-binding/correctness failure that happens to sit right after authorization, in a seam nobody explicitly owns: authz tools stop at "allowed," and the app/DB layer usually assumes whatever authz let through is automatically correct. Question: Is this split real, or am I inventing a distinction that doesn't matter in praactice? If you've built agent authz, did B ever come up as its own concern, or did it just get absorbed into "well obviously scope your queries correctly"? Is there existing terminology for B that I'm missing - is this just "row-level security" under a different name, or something else entirely?