A security layer for tool-using AI agents that validates intent, enforces permissions, and stops unsafe actions before they touch production. It gives engineering and security teams real control over what agents can and cannot do.
Role
Founding Engineer
Duration
2+ Months & Ongoing
Status
Most agent setups today work like this: the agent calls a tool, the tool runs, and you find out what happened from a log entry after the fact. If the action was destructive, there is no undo button.
Teams either give agents broad access so things just work, or lock them down so heavily that the agents can barely do anything useful. Existing tools were not designed to scope permissions at the tool-call level.
An agent starts with a clear objective, say, summarizing a report, but mid-workflow it decides to export the underlying dataset. Nothing in the current stack catches that shift.
When something goes wrong, teams end up piecing together raw API logs, trying to reconstruct what the agent was attempting and why. There is no structured record tying goal to action.
Instead of watching agents after they act, Valence sits between the agent and every tool call. Each action gets checked against the agent's stated goal and the policies the team has set. If it doesn't belong, it gets stopped before it runs.
Every tool call gets compared against the agent's declared goal. If an agent meant to generate a summary but tries to delete a table, that mismatch gets caught and the call gets blocked.
Teams define what each agent can touch, which tools, which actions, in which environments. Policies are versioned, so you can roll back if a change breaks something.
Dangerous actions get intercepted before they run, not after. If a tool call would delete production data or transmit records to an external endpoint, it gets stopped.
High-impact actions like financial transfers, bulk deletes, and permission changes pause and wait for a human to approve or reject them. Approvals have expiry windows.
Every tool call, every policy decision, every blocked action gets recorded with structured context: the agent's goal, what it tried to do, and which policy applied.
When something gets blocked or flagged, the right people know immediately through Slack, email, or webhooks. Alerts include the agent name and the exact reason it was stopped.
Building production-grade agent security required solving hard engineering problems.
Challenge: Injecting a security check into every single tool call without adding meaningful latency or disrupting the agent's execution flow. Agents need to feel autonomous, but every action has to pass through policy evaluation.
Solution: Built a lightweight SDK wrapper that intercepts tool calls at the runtime level, sends them to the decision API, and returns allow/block/approval-required responses in milliseconds.
Challenge: Evaluating tool-level permissions, goal alignment, and risk classification for every tool call fast enough to not become a bottleneck in production agent workflows.
Solution: Designed the policy engine to resolve decisions in-memory with Redis-backed caching for active policies. Average decision latency stays under 50ms even under high throughput.
Challenge: Comparing a loosely defined agent goal (natural language) against a specific tool call (structured data) reliably enough to catch real mismatches without flooding teams with false positives.
Solution: Used structured prompt templates with deterministic JSON outputs for goal classification. Combined semantic comparison with rule-based tool-action mapping to keep accuracy high and noise low.
Challenge: Pausing an agent mid-execution for human approval and resuming cleanly once approved, without the agent losing context or the workflow timing out.
Solution: Implemented a stateful approval lifecycle with pending/approved/rejected/expired states, configurable timeout windows, and clean resume hooks in the SDK.
Challenge: Preventing alert fatigue when an agent repeatedly attempts the same blocked action in quick succession, which can happen when agents retry on failure.
Solution: Added Redis TTL-based deduplication per agent-tool-action combination with a 60-second suppression window. Teams get one alert per unique violation pattern, not twenty.
Challenge: The same action should be allowed in staging but blocked in production. Policies need to understand deployment context without requiring duplicate policy sets.
Solution: Built environment scoping directly into the policy model. A single policy can specify different decisions per environment, so delete_record can be allowed in staging and blocked in production with one rule.
Our target outcomes for agent security enforcement and operational visibility.
| Metric | Without Valence | With Valence |
|---|---|---|
| Unsafe Action Detection | Post-execution logs | Pre-execution blocking |
| Permission Granularity | API-level | Tool-call-level |
| Goal Drift Visibility | None | Real-time |
| Incident Evidence | Raw API logs | Structured session replay |
As Founding Engineer, I am building the full-stack security platform. That includes the enforcement API, the policy engine, the TypeScript SDK, the approval workflows, and the control panel dashboard. My focus is on making sure every tool call goes through policy evaluation without adding meaningful latency, and that teams have clear, structured evidence of everything their agents do.