01
Policy scopeWhat counts as abuse.
The Acceptable Use Policy binds everyone who uses Intramedial, including in the demo workspace. In short: use the Service for lawful work on systems you are entitled to contact, do not abuse it, and do not misrepresent what a ledger record proves.
2.1Breaking the law or attacking others
- Registering upstreams, forwarding agent calls or sending requests to systems the sender has no right to contact.
- Scanning, probing or overloading third-party systems, including port scans, credential stuffing, denial of service or vulnerability scans run through forwarded agent calls or connector writes.
- Harvesting credentials, or sending spam, phishing or malware through connector writes or agent calls.
2.2Unlawful or infringing content
- Attesting or relaying content that is illegal, sexually exploits children, promotes violence or terrorism, or infringes intellectual property or privacy rights.
- Submitting personal data without a lawful basis, or putting secrets, health, financial or contact details in readable ledger fields.
2.3Misrepresenting the ledger
- Forging, altering or misrepresenting a ledger entry, or implying it proves more than it does.
- Presenting a demo ledger entry as a production record, or a reported fact as one Intramedial observed.
- Claiming that a ledger entry is legal advice or an independent audit, or that Intramedial endorses a product or content.
2.4Abusing the commercial model
- Circumventing allowances, rate limits, seat limits or the one-test-key-per-network limit, including with extra accounts or keys.
- Sharing a seat or keys beyond the organisation, or reselling the Service without written agreement.
2.5Interfering with the Service
- Bypassing authentication, tenancy isolation or the filter that blocks requests to private and internal addresses.
- Using automated means to create test keys or accounts at scale.
- Probing the Service or the signing keys outside the responsible disclosure policy.
Good-faith security research that follows the responsible disclosure policy is not a breach of the Acceptable Use Policy. Responsible disclosure policy
02
Site ownersIf you operate a destination receiving requests.
Three Intramedial paths make requests to an address a customer chooses. If one of them points at your system, this is what the traffic looks like and what we need to find its source.
Which tools reach your systems
| Tool | What reaches you | Pattern |
|---|
| mcp.enforce | One POST per admitted agent call: a JSON-RPC tools/call with the tool and its arguments. | On demand, per agent call. Always POST, with a JSON body. |
| saas.admit | One request to a SaaS tool's API, as the customer's write map names it. | On demand. Writes are held for a person to approve first. |
| mcp.session | A request to the host an agent asked for. | On demand, one per agent call. The method is the one the agent chose; timing is not yet stated. |
| github.enforce | Commit statuses and check runs posted to api.github.com for a connected repository. | On each gated write. Goes to GitHub's API and nowhere else. |
What we can tell you about the traffic
It comes from Cloudflare's network
Forwarded calls leave from Intramedial's gateway, so you see our address, not the customer's. We do not publish a fixed address range or user agent for this traffic, and the ledger entry names the agent.
Credentials come from the customer
A credential is the customer's own, leased from their connection at call time and sent only to the address they registered. We add no identity or signature headers of our own. The body is the agent's tool call.
Redirects are never followed
Redirect handling, timeouts and reply size limits are not yet stated for the gateway; the ledger entry records what came back.
Private addresses are refused
Which destinations a customer may register, and how each one is checked before a forwarded call is made, is not yet stated here, so ask us.
What helps us find the source
- The hostname and paths that received the requests.
- The first and last time you saw them, in UTC, and roughly how many.
- The method, the status codes you answered and any value that looks like a customer's own (a bearer token's prefix, a client id, a tool name). Never send a full secret.
- A ledger entry id, if anyone has shown you an entry for the traffic.
Your answers are part of the record. A forwarded call's ledger entry carries the status code you returned, and a high share of refusals from one host is a pattern our detection on forwarded calls looks for. You can refuse or rate-limit the traffic while we look.
03
Report checklistWhat to include in any report.
The Acceptable Use Policy asks for four things. The more exact they are, the faster we can tie a report to a workspace.
01What you saw
A plain description: what happened, to which system or person, and why you believe it breaks the policy.
02When, in UTC
The time of the first and last event. If your logs use a local time, say which zone.
03Identifiers
Any receipt id, URL or hostname involved. A receipt id is a 26-character code that starts with the time it was issued.
04How to reach you
An email address we can write to if we need more. We use it only for this report.
Please do not send API keys, passwords or other people's personal data beyond what the report needs. The form refuses a report that contains a full Intramedial API key or access token.
04
Review processWhat happens next.
Reports are reviewed and handled under section 3 of the Acceptable Use Policy. There is no automated decision, and we do not publish a turnaround time.
- Received
You get a reference of the form AR-20261026-XXXXXX on screen. Keep it for any follow-up.
- Reviewed by a person
We match the report to a workspace where we can. Automatic detection on forwarded calls can raise a flag, but a flag only asks a person to look.
- Action, by severity
We may warn the customer and ask for a fix; limit, revoke or suspend keys; suspend a workspace or account, immediately where there is harm or risk to others; or end access under the Terms.
- The customer is told why
We tell the customer why we acted, unless the law forbids it or telling them would put others at risk.
- What you hear back
We may ask you questions. We may not be able to tell you the outcome, because it concerns another customer's account. If you report content you believe is illegal under EU law, we tell you our decision about it and how to challenge it.
Serious crime
Where we believe a serious crime is involved, such as child sexual exploitation, or where the law requires it, we preserve evidence and report to law enforcement or other authorities.
05
AuthoritiesLaw enforcement and legal requests
This is what our published terms say about requests from courts, regulators and law enforcement. It is a summary; the linked documents are binding.
Valid legal process
We disclose personal data to courts, regulators and law enforcement where the law or a valid legal process requires it, and cooperate with valid legal process.
Privacy Policy §5 · Acceptable Use Policy §3
Requests for customer data
If a government asks for personal data we process for a customer, we tell the customer where the law permits, and disclose only what we are legally required to.
Data Processing Addendum §11
Governing law
The agreement with customers is governed by the laws of the State of Delaware, USA. The contracting entity is the company below.
Terms of Service §15
Which records exist, and which do not
- Ledger entries hold hashes and readable metadata: agent ids, tools, resources, decisions, the moment of the call and, for GitHub writes, the repository. They are kept for the customer's plan window.
- Forwarded call arguments and results are not stored; the history holds who asked, what for, the mode and the answer.
- Security-relevant events (sign-ins, key changes, denied access) are in an append-only audit log with the source IP address and user agent.
- Operational logs are kept for 30 days at most.
Source: Data and privacy
How to send a request
Use the form below and choose "Law enforcement or public authority", or write to abuse@intramedial.com. Address formal legal process to the company:
CompanyAvonao, Inc.
254 Chapman Rd, Ste 208 #21918
Newark, Delaware 19702
United States06
AppealsIf your workspace was flagged or suspended.
A workspace has one of four states: clean, flagged, under review or suspended. Detection never suspends and never lowers a status on its own; a suspension is a decision a person took on evidence.
cleanNo concern recorded.
flaggedA pattern asked a person to look. Your calls still run.
under_reviewA person is looking at the evidence.
suspendedAccess is suspended by a person's decision.
How to appeal
- Read the state and the reason, with the numbers that triggered it, in the dashboard.
- File an appeal of 50 to 5,000 characters from the dashboard. You get an appeal id back.
- Or write through the support page and quote the appeal id. A person reads every appeal.
Account API reference · Support
We do not give a fixed turnaround time. Fees are not refunded for access suspended or ended because of a breach of the Acceptable Use Policy.