InfoSec Rejected Our AI Agent Deployment

Treat the rejection as a requirements document: you need encryption, audit trails, approval gates, and clear blast-radius controls. You can satisfy most of that by putting a governed firewall like LetsPing in front of every destructive tool and persisting encrypted state and decisions for audit. This page maps common InfoSec objections to specific architectural controls and shows how to implement those controls with LetsPing without rewriting your entire stack.

1. Decode the rejection into concrete controls

Most InfoSec feedback falls into a few buckets:

No clear approval flow before destructive actions.
No audit log that ties actions back to humans or agents.
Payloads stored in plaintext in logs or databases.
Hard to prove which agent or model produced a given call.

2. Wrap destructive tools with HITL using LetsPing

Instead of letting agents call Stripe, Terraform, IAM, or your own admin APIs directly, route those calls through LetsPing. The agent invokes lp.ask() with a payload describing the action. A human approves, edits, or rejects from the dashboard or phone, and only your own backend ever calls the real tool.

Every decision is timestamped, signed, and tied to an actor id. That satisfies the “who approved what and when” question that InfoSec and auditors always ask.

3. Encrypt payloads so there is no plaintext at rest

With LETSPING_ENCRYPTION_KEY configured, payloads are encrypted client-side with AES-256-GCM before they ever leave your runtime. The database only sees { _lp_enc: true, iv, ct }. Even with full database access, an attacker cannot read sensitive content.

This gives you a clean answer to “what happens if your logs leak?” and sharply reduces blast radius.

4. Provide a verifiable audit trail

LetsPing stores decisions with resolved_at, actor_id, and optional method. On top of that you can export an audit log per project that shows which tools were called, with what payload, under which approval.

During a review you can hand InfoSec a concrete set of logs and architecture diagrams instead of vague assurances about “we log everything.”

5. Use signed proofs for higher-risk integrations

For cases where external services need to verify what your agents did, LetsPing exposes GET /api/agents/proof and GET /api/agents/handoff-outcome. These endpoints return signed receipts and ordered outcome history for each delivery id.

That gives InfoSec a forward path: they can allow higher-risk flows as long as the counterparty can verify actions using those receipts.