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