Skip to main content
Aona
Book a demo

For employees using AI

Human guardrails for AI use.

Catch risky tool use and sensitive sharing on covered employee AI paths.

THE MOMENT BEFORE SHARING

A support reply carries customer details into an AI draft.

Explore workplace examples Check the coverage
AI assistantSupport reply
Draft to share

Draft a reply to Alex Morgan at alex.morgan@example.invalid about account SAMPLE-104.

Prepared by an employee
Illustrative policy response
Customer details removed.

In this example, the configured policy replaces identified details before the supported submission continues.

Protected draft

Draft a reply to [CUSTOMER] at [EMAIL] about account [ACCOUNT].

Example policyCustomer identifiers

The protected fictional draft replaces the customer's name, email and account reference.

Fictional support task. No content is sent or evaluated here. Actual responses depend on the configured policy and supported input path.

Where mistakes happen

Everyday work creates the exposure.

Protecting people using AI starts with the tool they choose, the information they share and the answer they trust.

  1. 01 / Tool choice

    A tool is used outside the approved path.

    Review covered AI use to see where people work, then confirm the app and device path before setting a policy.

    Know the use
  2. 02 / What gets shared

    A prompt or file carries sensitive work.

    For supported inputs, a configured policy can block or redact information before submission.

    Apply the policy
  3. 03 / What gets trusted

    An AI answer is used without review.

    Check consequential output against its source before using it. An input policy does not verify every AI answer.

    Keep judgment

Across the team

Six tasks. One question: what is about to be shared?

Open a task to compare a fictional draft with its configured example response.

These are illustrations, not live policy tests. Confirm each tool, input and response in your deployment.

01Customer supportAccount follow upRedacted in this example
Original fictional draft

Draft a reply to Alex Morgan at alex.morgan@example.invalid about account SAMPLE-104.

Configured example response

Draft a reply to [CUSTOMER] at [EMAIL] about account [ACCOUNT].

Policy: Customer identifiers

Fictional customer details. Review the remaining context and permitted purpose before sharing.

02People teamLeave request summaryRedacted in this example
Original fictional draft

Summarise Taylor Reed's request for leave. Employee ID SAMPLE-082.

Configured example response

Summarise [EMPLOYEE]'s request for leave. Employee ID [ID].

Policy: Employee information

Fictional employee details. Redaction does not establish permission to share the remaining information.

03Legal teamContract reviewBlocked in this example
Original fictional draft

Review the confidential contract for Northstar Example Ltd, matter SAMPLE-319.

Configured example response

This submission is blocked by the example policy.

Policy: Confidential client work

Fictional client and matter. Use the organisation's approved process for confidential client work.

04Finance teamInvoice summaryRedacted in this example
Original fictional draft

Summarise the invoice for Example Supply Co. Payment account: DEMO-000123. Payment is due in 30 days.

Configured example response

Summarise the invoice for [SUPPLIER]. Payment account: [ACCOUNT]. Payment is due in 30 days.

Policy: Payment information

Fictional supplier and non-functional account reference. The example illustrates a policy response, not a live detector test.

05EngineeringDebugging an API errorBlocked in this example
Original fictional draft

Explain this error log: API token DEMO_NOT_A_VALID_TOKEN; request SAMPLE-503 returned 401.

Configured example response

This submission is blocked by the example policy.

Policy: Credentials and secrets

The token is deliberately invalid. Detection of a real credential must be evaluated on the supported input path.

06Sales teamProposal draftingBlocked in this example
Original fictional draft

Draft a proposal for Willow Example Co. Internal minimum price: AUD 42,000.

Configured example response

This submission is blocked by the example policy.

Policy: Confidential deal terms

Fictional deal terms. This policy protects confidential commercial context, even when the request contains no personal data.

A useful boundary

Test the app, device and input people actually use.

Aona applies configured responses to supported prompts and files on covered employee paths. Check representative allowed and prohibited inputs, then review the response and available evidence.

Review AI security coverage See the AI agent path

Where the controls overlap

One data rule. Two enforcement points.

Sensitive-data protection is one guardrail both paths can share. Agent actions need a separate decision about tool permissions and approval.

One fictional detailCustomer account SAMPLE-104
01 / HUMAN GUARDRAILS

A person puts it in a prompt.

Aona can apply a configured block or redaction on a supported, covered employee input path.

See the human path
02 / AI GUARDRAILS

An agent puts it in a payload.

An Aona API can return a content verdict at your checkpoint. Your application applies that result before it continues.

See the agent path

An Aona content result can inform an agent checkpoint. The application still controls whether the agent is allowed to act.

Keep going

Connect the control to the work.

Explore the types of guardrails

Review a specific framework without treating one guardrail as proof of compliance.

Questions

Your questions, answered.

What are human guardrails for AI use?
Human guardrails are AI guardrails for employees. They protect the way people use AI at work, including which tools they use and what information they submit. Aona applies configured policies on supported, covered endpoint paths. Depending on the policy and input, a response can include blocking or redaction, with evidence available for the organisation's review.
Are human guardrails the same as human-in-the-loop approval?
No. Human guardrails protect a person's use of AI, for example checking a prompt for confidential information. Human-in-the-loop approval is a separate control in which a person authorises an agent's proposed action or reviews an output. Aona's employee protection does not establish an approval-routing product feature.
Does the policy apply to every AI app on every device?
Coverage requires the relevant Aona client or an explicit API integration. The browser plugin supports Chrome, Edge, Firefox and Safari; application, input and file support can differ. Native coverage also depends on the app, action and operating system. Confirm your actual tools and representative tasks during scoping. A catalogue entry alone is not proof of enforcement.
What can our security team review?
Recorded AI usage and policy events can help your team understand covered activity and configured policy responses. Available records depend on the client, supported path, deployment and retention settings. Review access and retention with employee privacy in mind. These records are not a complete account of all work or a measure of employee productivity.
Does redacting a patient note make it HIPAA de-identified?
Removing detected identifiers does not establish HIPAA de-identification. Safe Harbor and Expert Determination have specific requirements, and remaining context can still identify a person. Your organisation must review the information, intended use, applicable agreements and safeguards. Aona's controls can support that process on covered paths.
Aona guardrails

Bring a real AI use case.

Map the data, policy and supported coverage with our team.

Book a demoReview product options