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,…
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,…
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…
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…
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…
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…
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,…
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…
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…
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…
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…
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…
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…
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,…
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,…
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…
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…
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…
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…
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,…
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…
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…
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…
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…
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…
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…