Suppose an AI response is blocked because it includes a private record. Blocking the answer matters, but if the record was already sent to an unauthorized model provider, the earlier disclosure has happened. This is why the timing of a control matters as much as its name.
Before the model: control the request
Pre-model controls decide whether the request may proceed and what it may contain. In a wellbeing app, that can mean checking the session, the account’s permissions, the permitted purpose, and which memories are relevant. A useful design keeps another person’s records out of the request entirely.
Example decisions before a model call
- Reject a request for context belonging to another account.
- Exclude a disconnected data source from retrieval.
- Limit a request to an approved provider and permitted purpose.
- Remove unnecessary identifiers before forwarding content, while recognizing that removing names alone does not guarantee anonymity.
After the model: inspect the result
Post-model checks assess the generated content and proposed actions. A model could produce an unsupported factual claim, disclose a sensitive detail, or suggest an action outside the application’s role even when the input was authorized. The response path needs its own decisions.
Example decisions after a model call
- Block an answer that includes content prohibited by the application’s policy.
- Require a qualified person to review a consequential output in a workflow designed for that review.
- Reject a tool request outside the user’s permissions.
- Show a clear fallback when the system cannot provide an acceptable answer.
Why prompt injection crosses the boundary
OWASP describes prompt injection as input that changes a model’s behavior in unintended ways, including instructions hidden in external material. Its recommended mitigations include constraining privileges, separating external content, and testing adversarial scenarios. No single prevention method eliminates the risk.[1]
Consider a retrieved document containing “ignore the previous rules.” A filter might miss that instruction. An external authorization check should still prevent the model from accessing another account or granting itself a new capability. The architecture should make the dangerous action unavailable, not merely ask the model to avoid it.
Follow one fictional request through both sides
A wellbeing example
The request
“Compare this week with last week.” The account has allowed its own notes, but no wearable access.
Before generation
The system retrieves permitted notes from the two weeks and leaves wearable data out. If permission is missing, it requests clarification or declines that part of the task.
After generation
The response is checked for unsupported clinical conclusions and policy violations. A summary should not turn a few notes into a diagnosis.
When a check fails
The user receives a clear explanation or a limited alternative. The system records the outcome and enough context for investigation without indiscriminately copying sensitive content into logs.
Test failures, not just the happy path
For an engineering team, the useful question is “What happens if this control is unavailable?” A timeout, stale consent decision, incorrect account mapping, or new provider configuration can expose gaps that a polished demo misses. Decide explicitly which operations stop and which limited fallback remains available.
A small review agenda
- Can an old permission decision be reused after access changes?
- Can the output path bypass a check through streaming, retries, or a tool call?
- Do error messages or monitoring logs accidentally contain personal information?
- Can investigators identify the policy, provider, and checks used for a disputed interaction?
- Who owns a failure, and how is a corrective change verified?
Where GMAI applies this distinction
MiAngel Middleware AI, or GMAI, places governance on both sides of the model call in its public architecture: identity, consent, and selected context before generation; response validation and an audit record afterward. That is the useful comparison to examine when evaluating infrastructure. A pre-model control and a post-model check are complementary, not interchangeable.
Neither side alone guarantees correctness or legal compliance. A complete service also depends on access management, operational security, appropriate product scope, testing, and people who can investigate problems. The strongest explanation makes those responsibilities visible.
Common questions
Can output filtering undo a privacy leak to a provider?
No. It may stop the user from seeing a result, but it cannot reverse information already sent upstream. Control the data before transmission.
Do pre-model controls remove the need to review output?
No. An authorized request can still produce an unsuitable or incorrect response.
Does an audit trail prove every control worked?
It records defined observations. You also need to evaluate coverage, integrity, missing events, and the reliability of the checks themselves.
