Skip to main content
Verified Actions are customer-approved tools that let Puntego read or change a narrow business object after policy checks. They are not a generic API agent.

​
Customer control model

Customers choose which actions are enabled. Every action starts disabled for a tenant until an owner enables the matching lane and action instance in the dashboard.
  • Curated templates are Puntego-owned cards with fixed schemas, risk class, identity requirements, confirmation requirements, and connector behavior.
  • Custom read-only actions can be added as manually scoped actions with one fixed base URL, one fixed path, one input schema, one output schema, and an explicit redaction map.
  • OpenAPI import is not supported. Customers cannot upload Swagger or OpenAPI documents to generate tools in this rollout.

​
Curated templates

The initial catalog contains these templates:
  • CRM lead lookup
  • Account entitlement lookup
  • Order status lookup
  • Inventory lookup
  • Support ticket creation
  • Support ticket creation with transcript and page context
  • Meeting booking
Customers choose which curated templates are enabled, and server-side policy still checks tenant flags, identity requirements, connector state, and rate limits before a template can execute. Support ticket creation ships with managed Zendesk and Intercom adapters. Connect Zendesk with either an API token (Basic auth — also supply the agent email the token belongs to and the account subdomain) or an OAuth access token (Bearer); connect Intercom with an access token. Credentials go into the connector credential vault, are encrypted at rest, and only the last four characters are ever shown back.

​
Identity and confirmation

  • General read-only lookups can run without visitor identity only when the template does not expose personal account data.
  • Personal reads require a visitor session or account identity before the connector runs.
  • Writes require visitor confirmation, idempotency, audit logging, and redacted request/result storage.
  • Connector output is untrusted. Puntego normalizes and redacts results before reuse in chat or replay.

​
Beta custom writes

Custom visitor-confirmed writes are Beta and are limited to reversible or low-risk categories such as creating a lead, creating a ticket, booking a meeting, adding to cart, applying a coupon, or updating a non-sensitive preference. The dashboard requires explicit Beta risk acknowledgement before a custom write can be created. A customer must provide the target system, visitor confirmation copy, and reversal or handoff instructions. Forbidden categories remain blocked:
  • refunds
  • cancellations
  • access changes
  • role changes
  • password, API-key, or security changes
  • payment or billing changes
  • contractual acceptance
  • broad exports
  • arbitrary webhooks or emails
  • regulated decisions
Custom writes outside the allowed Beta categories need owner or human handoff instead of direct execution.

​
Visible-page assistance

Visible-page assistance is controlled by customer settings and target/action manifests. The browser runtime can only use page actions that are enabled for the tenant and declared by the site’s manifest.
  • Form fill assistance covers visible, non-sensitive fields declared by the manifest.
  • Visible click assistance covers visible, enabled buttons or controls declared by the manifest.
  • Sensitive fields, hidden controls, disabled controls, destructive targets, undeclared selectors, and runtime-declared API tools stay blocked.
  • Runtime page manifests can declare visible page targets and actions only. They cannot declare server-side API actions.

​
Rollout checklist

  1. Enable only the tenant lanes required for the customer pilot.
  2. Enable curated templates one at a time and verify the connector health before production traffic.
  3. Add custom read-only actions only after reviewing the fixed host, fixed path, schemas, and redaction map.
  4. Keep Beta custom writes disabled unless the customer accepts the Beta risk copy and the action is reversible or low-risk.
  5. Confirm personal reads have an identity source before launch.
  6. Confirm visible form fill and visible click settings match the target/action manifest shipped on the site.
  7. Run replay QA for one allowed action, one declined confirmation, one blocked forbidden category, one stale credential, and one hidden or sensitive visible-page target.
  8. Review Needs Attention and audit logs for redaction before enabling the next action.

​
Deployment notes

  • Keep API actions server-side; do not expose customer secrets to the browser, prompts, logs, or model-visible context.
  • Keep Beta write copy visible in-product and require acknowledgement for every creation flow.
  • Treat stale credentials, schema failures, failed writes, stale visible targets, and policy blocks as Needs Attention items.
  • Roll back by disabling the action instance or tenant lane; do not widen tenant-wide policy to make a single action pass.