Agents request.
kiss verifies & executes.
Agents only request actions. kiss checks each one against your real business records, then executes only if the values match. Credentials never leave our infrastructure.
refund_customer(
order: "ord_9999",
amount: 95000
)In-scope refund, but the order doesn't match the ticket.
The blind spot
Authorized isn't the same as correct.
You've secured agent access: least privilege, short-lived credentials, policy checks. But an authorized agent can still be tricked into an in-scope action with the wrong values. Auth passes. Policy passes. The damage is done.
Refund to the wrong card
An under-limit refund from an authorized agent, sent to the attacker's card. Policy allows it. The order record doesn't.
Deploy to production
An approved deploy pushed to production, not the staging the PR targets. Authorization allows it. The PR record doesn't.
Export every account
An allowed export scoped to every account, not the one in the ticket. Permissions allow it. The ticket record doesn't.
The principle
Check intent against your business, then execute.
Agents decide whatto do. kiss decides if it's correct, checking each request against your real business data first.
"Refund $85 to cus_123."
Agent asks. Holds no credentials.
Static policies
- Within the agent's refund limit?
- Original payment method only?
Dynamic business values
- Matching, approved ticket?
- Order exists and totals exactly $85?
All checks pass.
kiss runs it with your credentials, never the agent's.
How it works
From intent to execution, in four steps.
Agent requests
It submits the action, parameters, and context. No credentials of its own.
kiss checks your business
We verify against identity, policy, and your records. Does the refund match the order? The deploy match the PR? If not, we block.
kiss executes
On approval, we run it through managed connectors. Keys never leave our infrastructure.
Everything is recorded
A complete record per action: who, what, the verdict, and result.
The business-logic layer
Others check if it's allowed. We check if it's right.
Identity and policy are table stakes. kiss adds the layer nobody else has: verifying the action's actual values against your system of record.
Identity
Which agent is asking, and which human is behind it?
Table stakes
Policy & scope
Is this agent allowed to perform this operation, within its limits?
Table stakes
Business-logic check
What no one else does
Do the action's values match the business record that justifies it? A deterministic check, no LLM guessing.
- Does the order ID match the originating ticket?
- Does the amount match the actual charge?
- Does the target environment match the linked PR?
- Does the payee match the vendor master record?
Values match the record → execute.
Mismatch → block or escalate.
Managed connectors
Same connectors, both directions.
kiss reads the system of record to run the check, then executes the action if the values match. Always kiss to system, never agent to system.
Stripe
OrdersRefunds
GitHub
Pull requestsDeploys
Salesforce
CasesRecord updates
AWS
ConfigsInfra changes
Jira
TicketsTransitions
Custom
Your recordsYour APIs
Audit trail
Every action leaves a complete record.
Execution happens inside kiss, so the log is the source of truth, not a reconstruction. Every record shows why an action ran or was blocked, and which business record it was checked against.
- Agent
- support-bot
- Human
- ana@company.com
- Action
- refund_customer(ord_9999, $950)
- Policy verdict
- pass · under limit
- Business-logic verdict
- fail · order ≠ ticket
- Reason
- ticket #4521 → order 1234, not 9999
- Decision
- blocked
- Execution
- not run
- Timestamp
- 2026-06-07 14:32 UTC
Authorized isn't enough. Make every agent action correct.
See how kiss verifies every action against your business and runs it, without ever sharing a credential.