Guardyx for Internal Copilots

Let your team’s copilots actually do things across internal systems, without handing them the keys to everything.

The scenario

Internal copilots have graduated from answering questions to actually doing things. They pull internal data, update records, kick off workflows, and take actions across HR, IT, finance, and ops, on an employee’s behalf.

Approval requested

Held for a human before it runs.

High riskPending

Agent: Workplace Copilot
Tool: GOOGLESHEETS_BATCH_GET

Arguments

{
  "sheet": "Salaries — Support team",
  "range": "A1:F40",
  "on_behalf_of": "j.rivera (Support manager)"
}

Policy

Reaching sensitive data at the edge of the requester’s role: approval required.

What can go wrong

A copilot surfaces something an employee shouldn’t see: salaries, HR records, another team’s confidential data. It acts beyond that person’s authority, or changes a system it shouldn’t touch. It can even become a quiet path for sensitive data to leak, or for a low-privilege user to reach high-privilege actions. The blast radius is every internal system the copilot can reach.

Who owns this problem

Your CISO and IT/security leadership own the risk. Your platform team, rolling copilots out across the company, owns the rollout.

What it looks like deployed

Guardyx sits in front of every action a copilot takes and enforces what each person and each tool is actually allowed to do. In-policy actions run; anything that crosses an authorization line, touches sensitive data, or changes a protected system gets checked and held for approval. Every action is logged against the person who triggered it.

Employee → Copilot calls a tool. Guardyx checks the action against your policy before it runs: in-policy actions execute against hr · it · finance · ops; exceptions hold for approval. Either way the decision is recorded.

Where held actions wait: each one with its risk, its agent, and the call it tried to make.

What you're covering

You get real least-privilege enforcement and a full record of every copilot action. You don’t have to write custom access rules into every integration. Your people get genuinely useful copilots, and security keeps a firm line around what they can reach.

How it fits your existing tools

Policies line up with your identity model through OIDC and role-based access control (RBAC). Approvals land in the Guardyx portal, Slack, or email. Every action is captured as an exportable, auditor-ready evidence pack. You set the per-role and per-tool rules, and exceptions are handled cleanly so day-to-day work keeps moving.

The approver sees the agent, the call, and the agent's own reason for it, marked unverified.

Every decision lands in the run record you export as evidence.

Example controls

A quick, plain-language picture of the policy decisions you'd set:

Allow: In-scope reads and actions that fall within the user’s own role.
Hold for a human: Reaching sensitive data or acting near an authorization boundary.
Deny: Actions beyond the user’s privilege, or changes to a protected system.

Without Guardyx / With Guardyx

The exposure today, next to the controlled state with Guardyx
Without Guardyx	With Guardyx
A copilot can reach data or actions beyond the user’s role.	Every action is checked against that user’s real privileges.
Access rules get hand-coded into each integration.	One control layer enforces least privilege everywhere.
No clear record of who did what through the copilot.	Every action is logged against the person who triggered it.

Without: A copilot can reach data or actions beyond the user’s role.
With Guardyx: Every action is checked against that user’s real privileges.
Without: Access rules get hand-coded into each integration.
With Guardyx: One control layer enforces least privilege everywhere.
Without: No clear record of who did what through the copilot.
With Guardyx: Every action is logged against the person who triggered it.

The routine clears in one move; only the risky calls wait for a person.

See all seven use cases