groviqo

Trust by design

Automation only works when access is boringly well controlled.

Groviqo is designed around scoped access, secret boundaries, approval policy and auditable actions instead of passing credentials around the application.

Runtime Governance & Policy Boundaries

PostgreSQL RLS, FinOps caps, and human sign-off gates enforced at runtime.

ILLUSTRATIVE AUDIT STRUCTURE — NOT CUSTOMER ACTIVITY

Autonomous growth without a black box

No agent activity loaded. Review each question against its source record; missing data stays unavailable.

Which agent acted?
Actor identity and type in the activity record; explicit agent identifiers depend on the producer.
Why?
The recorded reason, not an inferred rationale.
What information did it use?
Evidence references where recorded; unavailable evidence stays missing.
Which provider/model was used?
Separate provider-usage records; model attribution is optional and is not returned by the activity API.
What action did it propose?
The proposal and change comparison in their own workflow records, where available.
Was approval required?
The relevant policy decision and approval request, separate from the activity summary.
Who approved?
The approval decision record identifies the approver; actor identity alone does not establish approval.
What did it execute?
Execution and provider results where supported; a proposal or approval is not execution.
Did it succeed?
The recorded outcome and any separate verification evidence; success does not prove growth.
What did it cost?
Measured request cost from matching usage records with complete actual costs in one currency; not a guaranteed per-action total.
What happened afterwards?
Later verification, change history and measurement records where connected; not inferred from the audit outcome.

The activity screen exposes actor, action, reason, evidence, outcome, time and measured request cost where available. It is not a unified view of prompts, models, approvals or post-execution verification.

Audit access is permission- and tenant-scoped. Credentials stay behind the SecretStore boundary. Audit records do not promise cryptographic signing; rollback depends on workflow and provider support.

OPERATIONAL STANDARDS

How the capability works

Least access needed

Read-only sources should stay read-only. Write-capable providers should be limited to the workflows and permissions that actually need them.

Secrets stay out of prompts and UI copy

Credential handling belongs behind the secret-store boundary and should never be treated as ordinary application content.

Autonomous growth without a black box

Agent Activity shows recorded actors, actions, reasons, evidence, outcomes and timestamps. These eleven questions guide review across separate records from the relevant sources; they are not a promise of one complete, joined audit view.

  • Which agent acted? Actor identity and type in the activity record; explicit agent identifiers depend on the producer.
  • Why? The recorded reason, not an inferred rationale.
  • What information did it use? Evidence references where recorded; unavailable evidence stays missing.
  • Which provider/model was used? Separate provider-usage records; model attribution is optional and is not returned by the activity API.
  • What action did it propose? The proposal and change comparison in their own workflow records, where available.
  • Was approval required? The relevant policy decision and approval request, separate from the activity summary.
  • Who approved? The approval decision record identifies the approver; actor identity alone does not establish approval.
  • What did it execute? Execution and provider results where supported; a proposal or approval is not execution.
  • Did it succeed? The recorded outcome and any separate verification evidence; success does not prove growth.
  • What did it cost? Measured request cost from matching usage records with complete actual costs in one currency; not a guaranteed per-action total.
  • What happened afterwards? Later verification, change history and measurement records where connected; not inferred from the audit outcome.

Recorded evidence, explicit gaps

No recorded activity is an empty state. Missing provider, model, approval, cost or verification data remains unavailable. Request-level cost is shown only when matching usage has complete actual costs in one currency; it is neither an estimate nor a complete invoice. Audit records do not universally store prompts, prior state or crawl verification.

Want to see what your site is missing?

Connect your domain, inspect the evidence, and use Groviqo to prioritize the next growth moves.

Start at your pace. Connect your data sources, surface high-impact opportunities, and execute improvements with total control.