Proof, on demand
A guarded check hits the real endpoint and returns the live status, latency, and result — evidence that a doc snippet can't provide.
Live verification
Answers backed by proof
When credentials and route rules allow, Woes can run a guarded live check against a real endpoint and show the status — so answers come with proof, not just prose.
guarded check · runner
GET/v1/orders Bearer ••••
200 OK142ms · verified
{ "status": "paid", "id": "ord_9f2" }
Real endpoint statusEncrypted credentialsRoute-level guardrails
The problem
Docs describe the API. They don't run it.
A developer says an endpoint returns a 401 and your docs say it shouldn't. Static context can't settle that — someone has to actually call the API. But handing production credentials to a support tool is exactly the risk teams are right to fear. Verification and safety usually pull in opposite directions.
Why it works
Sometimes the right answer isn't in the docs — it's whatever the API returns right now.
Credentials stay sealed
Auth material is encrypted at rest, redacted before model calls, and never returned in plaintext. The agent uses a credential without ever seeing it.
Only where you allow it
Checks run only when credentials and route-level rules are configured. No rule, no call — verification is opt-in per route.
response · verified just now200 ok
GET/v1/orders/ord_9f2
200 OK142ms · verified
attached to the answerProof, in the light
Answers you can verify at a glance
When a question turns on live behavior, Woes runs a guarded check with encrypted credentials and shows what actually came back. The answer stops being 'the docs say' and becomes 'here's what your API returned just now.'
Verify
Answer with the endpoint's real response
When a question turns on live behavior, Woes can execute a guarded request and show what actually came back — status code, timing, and result. The answer stops being 'the docs say' and becomes 'here's what your API returned just now.'
- Live status, latency, and result on the thread
- Verification attached to the grounded answer
- Runs only against configured, allowed routes
response · what it returned nowlive
Guardrails
Verification that respects the trust boundary
A live check is never a blank cheque. It runs inside route-level controls the workspace sets, using encrypted credentials the agent can invoke but never read. If a route isn't allowed, the check simply doesn't happen — and the agent falls back to a grounded, cited answer.
- Route-level rules gate every live call
- Encrypted credentials, redacted before model calls
- Falls back to cited context when a route is off-limits
route rules · what may run
Evidence
Every check is recorded and reviewable
Guarded checks leave an operator-visible record: what was called, what came back, and how it shaped the answer. Sensitive values are redacted in the trace, so you get accountability without exposing secrets.
- Operator-visible record of each guarded check
- Sensitive values redacted in the trace
- Clear link between the check and the answer
check record · operator view
How it works
Three steps, no heavy lift.
01step
Configure a route
Add encrypted credentials and set the route-level rules that decide what may be called.
route rules + sealed credentials
02step
Run a guarded check
When a question needs it, Woes calls the allowed endpoint using the sealed credential.
GET /v1/orders · Bearer ••••
03step
Show the proof
The live status is attached to the grounded answer, with the check recorded for operators.
200 OK · 142ms · verified
live
endpoint status
0
plaintext credentials
per-route
guardrails
FAQ
Guarded live API checks questions
Does Woes call my API automatically?
Only when you've configured credentials and route-level rules that allow it. If a route isn't explicitly permitted, no live call happens — the agent falls back to a grounded, cited answer.
How are the credentials protected?
Credentials are stored encrypted at rest, kept separate from source content, redacted before any model call, and never returned in plaintext. The agent can use a credential without ever seeing its value.
What does a live check actually return?
The real response status, timing, and result of the guarded request, attached to the answer as evidence and recorded in an operator-visible, redacted trace.
What if verification isn't possible for a question?
The agent answers from your grounded, cited API context instead. Live checks augment answers where they're allowed; they never replace grounding.
Back answers with live proof
Let the agent verify against a real endpoint — safely, inside the guardrails you set.