Skip to main content

Platform security

Three questions decide whether an agent platform is safe to put real work through: can another customer reach my data, where can a tool send it, and what protects the credentials that open the door. This page answers each one with what is guaranteed and what is not, so you can evaluate the answer rather than take it.

Credential storage and identity have their own articles - see Credential handling for how integration secrets are encrypted, scoped, and removed.

Workspace isolation​

Every tenant-owned record carries the organization that owns it, and that ownership is part of how the record is read, not a label attached afterwards.

  • Reads are scoped, not filtered late. Every read is constrained to your organization before it happens, so a record belonging to another workspace is never loaded and then hidden - it is never loaded.
  • Ownership cannot cross a workspace. A record can only reference records of its own organization, so a relationship can never span two workspaces, whatever asked for it.
  • A second floor sits under the first. Beneath that scoping, a request running inside an organization that somehow omitted its scope returns nothing rather than another tenant's records, and a write aimed at another organization is refused outright. This is defense in depth, adopted path by path rather than replacing the scoping above.
  • New kinds of record are held to it. A new tenant-owned record type cannot ship without the same protection.

When Yekar.AI staff need access​

Support access is never ambient. A staff member acting inside your workspace does so under an explicit, recorded grant with a read or write mode, an idle timeout, an absolute expiry, and a kill switch that ends it immediately. Routes that write credentials are blocked for the duration, so a support session can never store a secret in your name. The session's audit rows carry the grant that produced them, which is what keeps the record readable long after the session is over.

See Audit before effect for the trail every action leaves, and Permissions for the roles that bound your own team.

What a tool can reach​

A compromised tool - a prompt-injected argument, a hostile upstream response, a bug in a connector - is only as dangerous as the network it can reach. Yekar.AI routes every outbound request from a shipped integration through a single door and enforces the tool's own declaration there.

  • Declaring nothing means reaching nothing. A tool that does not declare where it may send traffic gets no outbound capability at all. Omission is refusal, not permission.
  • Hosts are matched exactly or by verified suffix. A declared api.example.com admits itself and its subdomains, and never a lookalike domain that merely ends in the same letters.
  • Addresses are checked before the request leaves. The resolved address is tested against private and reserved ranges first, so a public hostname pointed at an internal or cloud-metadata address is refused rather than fetched.
  • Redirects never inherit clearance. A redirect is either an error or surfaced to the caller; the next request re-clears every check from the start, so a hop can never carry the first request's approval somewhere it would not have been allowed.
  • Exceptions are enumerated, not ambient. Where a vendor's own client library cannot use the shared door, that integration applies the same address guard itself, and the list of such exceptions is fixed and reviewed rather than open.

Every attempt is recorded by destination - the hostname and the address actually dialed, never the path or query - so the record of where a tool reached does not itself become a place secrets accumulate.

Some integrations go further and never see their own secret: the integration works with a placeholder, and the real value is substituted after the destination checks have already passed. An integration that tried to send that secret somewhere else would be sending the placeholder.

Sign-in and API credentials​

  • Passwords are hashed with Argon2id, the memory-hard function, and are never stored or logged in a recoverable form.
  • API keys are shown once. A key is random 32-byte material; only its hash is stored, alongside a short hint so you can tell keys apart in a list. Yekar.AI cannot show you an existing key again, because Yekar.AI does not have it.

For machine access, see Authentication.

What this page does not claim​

Yekar.AI contains a credential up to the moment it is used, and using it is the point of the call - once a request reaches a vendor, their systems hold it under their terms.

Secret scrubbing across execution output is defense in depth rather than a guarantee: exact values and their common encodings are removed from the paths Yekar.AI controls, but a provider that transforms or splits a secret into an unrecognized form can defeat any scanner. Keep credentials out of agent-authored content and knowledge articles.

Yekar.AI does not currently claim any third-party security certification. Where a specific control matters to your procurement process, ask - a straight answer about what exists is more useful than a badge.

Where to go next​