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 the mechanism behind it, 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 identifier is part of how the record is read, not a label attached afterwards.

  • Reads are scoped, not filtered late. Service queries constrain on the organization at the database, so a record belonging to another workspace is never loaded and then hidden.
  • The database enforces the pairing. Tenant-owned rows use composite foreign keys that include the organization id, so a reference can never cross a workspace boundary even if application code asks it to.
  • A lint rule blocks the shortcut. Fetching an organization-scoped record by primary key alone is refused in review; the query must name the organization too. Exceptions are written down with their reason next to the code.
  • A second floor sits under the first. Every tenant table carries a database-level row-security policy. Where a request runs inside an organization scope, a query that omitted its organization filter returns nothing instead of another tenant's rows, and a write aimed at another organization is refused outright. This is defense in depth beneath the scoping above, and it is being adopted path by path rather than replacing it.
  • Future tables are held to it. An automated check fails the build if a new tenant table ships without the policy, and prints the definition it needs.

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 SDK cannot use the shared door, that integration reproduces the same address guard itself, and an automated check pins the exception list so it cannot quietly grow.

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 hand the handler its own secret: the code receives a placeholder, and the real value is substituted after the destination checks have already passed. A handler 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​