Permission-aware AI is a product architecture, not a prompt
Why useful AI for people operations needs identity, scoped tools, server authorization, draft states, denied states, and audit outcomes.
The tempting but weak approach
The weak version of AI in a people platform is easy to describe: paste private context into a model, tell it not to reveal anything sensitive, and hope the instruction holds. That is not a durable product boundary. People operations contains pay, reviews, personal contact details, candidate records, survey answers, and manager-only decisions. The system cannot rely on a sentence in a prompt to decide who may see or change those records.
Permission-aware AI starts with the same principle as the rest of the product: the actor matters. A manager, HR partner, employee, accountant, and owner may ask similar questions, but the permitted records and actions are different.
Carry the user identity into every tool call
The assistant should not receive a giant export. It should call small product tools as the current user. If the user asks who is away next week, the time-off read uses that user's scope. If the user asks to create a goal, the goals service still checks who can create it and for whom.
This is why Perelan Assistant is described as a workspace assistant, not a separate super-user. It is useful because it can reach the right product tools, and trustworthy because those tools keep their own authorization logic.
Separate read, draft, submit, and publish
People systems need more than allowed and denied. A self-review can be private while drafting and visible after submission. A pay change can be drafted, approved, and published. A generated dashboard can exist for its creator before it is shared.
Designing these states explicitly gives AI a safer job. It can help draft text, summarize context, or prepare a request without quietly crossing into a submit or publish action.
| State | Product meaning | AI behavior |
|---|---|---|
| Read | User may view scoped data | Answer with visible facts |
| Draft | User is preparing work | Save privately where supported |
| Submit | User makes content visible | Require explicit intent |
| Publish | Source record changes state | Use product authorization |
Recheck access after roles change
Access is not permanent. Managers change teams, employees leave, roles move, and group scopes are updated. Agents, saved views, and MCP tokens need to use current access, not the permissions someone had when the artifact was created.
That is why token and agent stories should say "inherits current access" rather than "was approved once." A stale approval should not become a hidden back door.
Design the denied state
A denied state should be boring and clear. The user should learn that the action is not available without learning hidden facts. "You do not have access to compensation for that employee" is safer than leaking whether a salary change exists.
What buyers should ask
Ask whether AI actions go through server-side authorization, whether drafts and submissions are separate, whether generated artifacts can bypass sharing rules, whether personal tokens are revocable, and whether denied actions are audited or observable. The answers reveal whether the AI boundary is architecture or theater.
Next step