kdodhia

hey Shalom! Good list, agree that's where most incidents come from. on your two questions:

- every outbound request goes through our proxy. the agent never holds the downstream credential so there's no path around it, and policy is evaluated deterministically there, not by the model. every call gets an audit row, denials included, with the agent, the end user it was acting for, the delegation chain, the grant, the operation, and the policy decision plus which rule produced it. so "user X did Y on Z at T and here's why it was allowed" is answerable after the fact

- User to resource mapping, honest answer is it depends on the credential. Where the provider supports it we push per-user oauth, so each end user connects their own account and the provider's own ownership checks apply. that's the cleanest least privilege - With a shared key we can't know who owns invoice 123 unless something tells us. what we do have is rules on the operation and its params (methods, paths, ids, recipients, amounts), so you can pin a user or agent to specific resources. but we don't keep a general ownership graph of your customers' data, that mapping still lives with you or the provider

On the rest: agents can only ever get a subset of the user's permissions (delegation narrows, never widens), money moving and destructive ops can require human approval on the exact frozen request, and our ai review can only escalate to a human, never allow something the rules didn't

hey Nishit, kevan here. sorry we completely missed your comment and your question

short answer is no, the policy engine doesn't know where an argument came from across calls. each call is judged on its own: which agent, which end user it's acting for (plus the delegation chain), which grant, which operation and the params on the request. so in your example the contractor's send passes if their policy allows it

we put the controls at the two ends instead of following the data through the middle - write side: the CEO's grant posting into a shared channel is its own call, so you can require approval for it or just deny it - send side: we parse sends into recipients, so a contractor can be limited to emailing inside the company domain, or anything external needs a human approval on the exact frozen request

every call is audited with the agent, end user and grant, and calls in the same run share a trace id. your case spans two sessions though, so the thing linking them is the slack message itself, not a trace

your noise point is honestly why we haven't done taint tracking yet, the "user typed the address but it was also in tool output" case is exactly the hard bit. it's a really interesting scenario though, we'll look into whether it makes sense for us to support this kind of thing natively.

Not today, no. Right now it's TLS plus the agent's Alter key, and every request is signed with that key. Each signature is timestamped and single use, so a captured request can't be replayed or tampered with. You can also lock a key to specific IP ranges, scope it down to just what that agent needs, and give it an expiry, so a leaked key is pretty limited in what it can do and where from. mTLS is a fair ask though, especially for people running agents in their own infra, and it's something we'd look at adding

When approval is needed the agent gets a link back for each approver, and most people just push that wherever their team already lives, a Slack DM, an in-app notification etc. We can also email the approver directly if the policy is set up with email notifications. The link itself doesn't approve anything, the approver has to sign in and only the person designated as approver can even open it. Then they see the full request that's going to run and approve or deny it

It doesn't sit there blocked. The call comes back right away with a pending status and an approval id, so the agent can tell the user "this needs sign off from X" and get on with other stuff. Then you either await it inline with a timeout or stash the id and have a worker poll it later. Once it's approved we run the exact request that was approved and the agent gets the provider's response back. If nobody answers in time it expires (10 min by default, you can set it up to 24h) and the agent has to make the call again.

Yeah we've put most of our effort so far into security, this part especially. Keys are encrypted in a dedicated secrets vault and once saved nobody can read them back, not even the dev who set them up. In proxy mode the key never even reaches the agent, we inject it on our side and only into requests going to hosts that are allowlisted for that provider. Every use gets checked against policy and logged with who used it and on whose behalf

Every change we ship gets scanned for supply chain attacks and goes through static code scanners too. We've been pen tested by two separate firms and we're in the observation period for SOC 2 type 2, details are at trust.alterauth.com. We're also planning open sourcing the full platform soon so you'll be able to look at the code yourself.

Makes sense, sounds like a solid setup. If your agents ever start calling cloud/internal APIs directly instead of going through the PR flow, that's exactly what we built Alter for, and we'd love to help. Either way, good luck with it!

Yup, the constraint isn't on the network, it's on the credential. The provider token or API key lives in our vault and the agent never sees it. All the agent holds is an Alter key, and the only thing that key can do is ask us to make a call. We check policy against the actual request, inject the credential and send it ourselves

So say the agent goes around us and hits the API directly. It has nothing to authenticate with, and the provider returns a 401. It also can't use us to leak the credential: for API-key credentials, we only inject them into requests going to hosts you've allowlisted for that provider, so pointing the call at its own server gets blocked before the key is attached.

To make it airtight, mint the agent's Alter key with proxy-only permission. We also have a mode where the SDK fetches the token for each call, but that's a separate permission and a proxy-only key can't use it.

Where it does break down is credentials we don't hold. If someone leaves a personal API key in the agent's environment, the agent can use it directly and we'll never see that traffic. Locking down outbound network access closes that gap, but that's on your infra side.

Yeah, sounds very close. The main thing we did to keep it deterministic is that nothing at request time is a model call. Rules are evaluated in the proxy against the actual request: method and path, the provider operation it maps to (we classify each provider's API into operations and families like delete or payment, from their published spec), parameter values, IP, time window, quotas. Default deny, and every rule can only narrow.

The other half is treating policy like code. Rules live in a file with test fixtures ("this request should be denied, this one should need approval"), `alter policy test` runs them, and `plan` / `apply` works like Terraform: you review a diff, and apply refuses if the plan was edited or the live policy changed since you reviewed it. `alter policy simulate` shows which rule fired for a given request and why.

Hey! Kevan here. Yes, it's its own thing. We classify each provider's API operations into families, and "payment" (anything that moves money or changes billing) is one of them, so a rule can target payments without you listing endpoints.

On your three controls:

- Per-action caps: rules can match request params numerically, so "deny if amount > 5000" works today.

- Approval above a threshold: same matching drives human approval, e.g. "require approval on payments where amount > 1000". The approver sees the exact frozen request that will execute.

- Rolling daily budget: not built yet. Today we have per-agent quotas that count calls per minute/hour/day, but nothing that sums amounts across calls. We have the pieces (amount parsing per call, per-window counters, approvals), so it's a natural next rule type.

Makes sense. On not being able to get read-only creds from the endpoint: that's actually where a proxy helps most. A big part of what we've built is giving you fine-grained permissions even when the underlying provider doesn't have them. The key can be full-power, but the agent only ever reaches the API through the proxy, so "GET only under these paths" is enforced there and a write never reaches the provider even though the key could do it.

On the compliance subagent, the one thing I'd watch is that it reads the same untrusted context as the agent, so it can be injected too. We treat the model as advisory only. We have an AI review rule that rates a request's risk, but it can only escalate to a human approval. It can't deny, and it can't allow anything the deterministic rules didn't already allow, so a fooled reviewer costs you an extra approval, never a bad action. Your impact-level classification maps pretty directly onto that.

Approved calls run at most once. Execution is claimed atomically so two workers can't both run it, and if the agent re-sends the same call it doesn't re-run the approved one, it creates a new approval that needs its own yes. If the provider call fails before the request ever left (connection refused, DNS) we retry. If it might have reached the provider, like a timeout on a POST, we don't resend. The approval fails as "outcome unknown" so someone checks the provider instead of guessing. Agree a duplicate after approval is as bad as no approval.

Hey @luis_valerio, kevan here! That question shaped most of the design.

We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer. Enforcement happens at the proxy, which sits between the agent and the downstream API and is the only thing holding the credential. The agent never sees the key, so an injected agent can't bypass it or route around the deterministic policy.

For irreversible actions you stack three things:

1. Method/endpoint restrictions. "This agent may only GET under /instances/*" means a DELETE never reaches the provider. For infra agents we'd push read-only by default and allowlist the few mutations you need.

2. Human-in-the-loop on the dangerous ops. Approval can be required conditionally: on DELETE, on specific operations, or when a parameter matches (resource outside the allowed set, etc). The request is frozen server-side, so what the approver sees is exactly what executes. The agent can't swap the payload after the yes.

3. Audit logs on every call, including denials, with the agent and end-user identity attached. So you can see the agent tried a DELETE it wasn't allowed, on whose behalf, and with what body.

Basically we treat every call like a compromised laptop: don't assume it behaves, scope the credential, and gate the risky actions behind a second party. Would love to hear more about your setup.