Why Your Platform Needs to Be Secure: What We Can Learn From the Railway and Primcloud Incident

Much of the public argument over the Railway Primcloud incident is about whether a Railway engineer meant it. That matters to the people involved. It will not change what you do on Monday.

Two other questions will. First, what separates a penetration test from everything else? Written permission and a scope, and an autonomous agent supplies neither for itself. Second, what do the reported steps say about your own platform? Primcloud's founder says every attempt on his was blocked. If nobody has tried the same steps on yours, you do not know whether you could say that.

This post is for anyone who runs AI agents against systems they do not own, or who holds other people's data and has never commissioned a test.

What happened in the Railway Primcloud incident?

The Railway Primcloud incident became public at 03:27 UTC on 3 November 2026, Monday night in the US, when Primcloud founder Josh Manders accused a Railway employee on X of "trying to breach" his infrastructure. A Railway engineer replied that the activity was his. Manders runs a competitor of Railway. Every technical step below comes from his account and a screenshot he posted, neither independently verified.

Here is what that establishes. The engineer's reply confirms the activity was his and gives his explanation. It does not confirm Manders's list, and Railway has neither confirmed nor denied that list in anything we read. RuntimeWire, writing hours before that list appeared, said the method and degree of access had not been proven in public. explainx.ai points out that the list comes from the target and, when it wrote, had not been compared with Railway's agent logs.

Intent is disputed: Manders says "done on purpose", the engineer says no malice. Still unknown are the instructions the agents had, whether the secrets request reached anything, whether other platforms were probed and what "appropriate action" means. The Stack says Railway acknowledged its request for more detail but gave none. Nothing we read reports legal action.

The Stack's headline says an employee "hacked" a competitor, and Security Boulevard's says agents "Breach Systems" of a rival. The only account of the outcome, from that competitor's founder, says nothing was accessed. Keep that gap in mind when you read the coverage. Reaction on X split. One developer called it overblown before Manders posted his list. Another, who had called it unauthorized pen-testing, criticized Manders for using it to promote Primcloud. The Stack wrote that this kind of hacking is a serious crime in the US, UK and other countries, which is the outlet's framing and not a finding about this case.

RuntimeWire and Security Boulevard also report that Cooper apologized and promised to ban non-manual external testing. We could not open the original reply, so this is second-hand. His later statement repeats neither the apology nor the ban, though it says Railway is reinforcing its expectations for employee conduct, and we could find no written Railway policy on this as of 5 November.

One thing to keep apart: Railway disclosed its own security incident on 21 October. Timing is the only connection on record. No source we read links the two, and Railway's preliminary report on October predates this dispute.

Was the Railway and Primcloud incident a penetration test?

A penetration test is a permitted exercise: the owner of a system agrees in writing to what will be tested and how. Nobody involved in the Railway and Primcloud incident says Primcloud gave permission, and nobody has described it as a commissioned test. That is as far as the public record goes. We draw no conclusion about law, contract or intent.

Several accounts were given that day: a guess at first-time user experience testing on other providers, which Cooper's statement later called a potential explanation based on limited information; signups and agentic testing on similar platforms (the engineer); an agent gone "off the rails" (Cooper's replies, as reported); and a personal tool for bug bounties (Cooper's statement).

Primcloud's Acceptable Use Policy, last changed on 4 May 2026, bars probing or testing its systems, or doing security research on the service, without "prior written consent". Whether those terms bind the engineer is not established, and we do not say they do. The policy matters here as an example of where a platform draws the line, which is the same place the testing standards draw it.

In general, the same step can be a commissioned test, unsolicited research or an attack. A scan of a network, run by someone the owner hired under a signed scope, is routine work. The technique does not tell you which one you are looking at. For a commissioned test, the paperwork does. An account on a platform gets you the use of a product, and our reading is that it gets you nothing more.

What makes a penetration test legitimate?

A legitimate penetration test has three things before anyone touches a system: a signed permission document from the owner, a scope saying what will be tested, and rules of engagement saying how. PTES, the Penetration Testing Execution Standard, treats scope and rules of engagement separately and says testing must wait for the customer's signature.

Other sources add detail that catches people out:

• Authority covers defined activities. NIST's glossary, citing SP 800-115, says rules of engagement give the test team authority for defined activities without further permissions, so those activities need spelling out.
• Your client cannot speak for its suppliers. PTES warns that a client's permission does not cover its third-party providers, so an app hosted on someone else's cloud raises a second question.
• The tester carries the damage. AWS makes you responsible for harm your testing causes to AWS or its other customers.
• Other customers are off limits. Microsoft's rules of engagement prohibit testing customer systems without explicit permission.

The law, in general terms, points the same way. This is not legal advice, and we draw no conclusion from it about anyone in this story. In the US, 18 U.S.C. 1030(a)(2)(C) covers intentionally accessing a computer without authorization, or exceeding authorized access, and thereby obtaining information from a protected computer. Subsection (b) separately covers attempts and conspiracy. The Justice Department's charging policy, updated in May 2022, tells prosecutors to decline good-faith security research, narrowly defined as accessing a computer solely for good-faith testing, investigation or correction of a flaw, in a way designed to avoid harm, with the results used primarily to promote security, but says it creates no enforceable right. In the UK, section 1 of the Computer Misuse Act 1990 makes it an offense to cause a computer to perform a function intending to secure access you know is unauthorized. In the UAE, a 2022 LexisNexis summary says Article 2 of Federal Decree-Law 34 of 2021 penalizes hacking a website, information system or network. We could not check later amendments.

How do you stop an AI testing agent going beyond its scope?

Stop an AI testing agent going beyond its scope by enforcing that scope outside the model, because an agent is given a goal, not a boundary. It tries what seems useful next until something stops it. We do not know what instructions the agents in this case had, but the engineer's own description of a harness reaching too far is the general risk in a sentence.

Speed makes it worse. Manders counts about 24 commands over 15 minutes, and Cooper's statement says the tool was stopped within 15 minutes. We do not know how closely this run was watched. In general, an unattended agent can do a lot before a person looks up.

Ownership is the other surprise. Cooper's statement describes personal accounts, a personal card and time outside work, and Railway's co-founder was still answering for it the same day. If your engineers run agents, the question may reach you whichever card paid.

The same statement says Railway's on-call engineers were told to red team Railway's own infrastructure, under "specific policies and short lived grants", and presents that as separate from the employee's tool. Read neutrally, the phrase is a fair picture of a boundary: a stated rule, and access that expires. In practice, that means:

• Permitted targets enforced by the network. A prompt asks the model to stay in scope. An egress rule makes leaving it fail.
• Credentials limited to the target, which expire when the run ends.
• A person approving high-impact actions. OWASP's LLM Top 10 recommends this under excessive agency (LLM06:2025).
• A stop switch and a full log, so you can halt a run at once and say afterwards what it did.

Our post on governing AI agents covers the wider version of this for agents in production.

Can a customer's container reach other customers' secrets on your platform?

Whether a customer's container can reach other customers' secrets on your platform is a question you answer by trying it, with sign-off, on your own system. Manders says that is what was tried against Primcloud, and that it failed. If nobody has tried it on your platform, you are assuming the answer. Each step he lists converts into a question about your own system.

The steps below are Manders's account, not verified fact. The controls use Kubernetes and AWS documentation as worked examples, which is not a claim about what Primcloud runs.

Look at how many of these are defaults. Pods accept inbound connections until a policy selects them, and AWS's documentation says instances accept either metadata service version by default, though the AMI, the account default, the launch settings and some newer instance types can change that, so check what yours do. A team that never made a decision may still have made one.

Network isolation is also only one layer. Tenant isolation in the database is a separate check, and credentials that work where they should not are a recurring theme in cloud security generally.

Is penetration testing or VAPT mandatory?

Penetration testing, or VAPT, is not a universal legal requirement. It is required by name for specific groups. Vendors say SOC 2 and ISO 27001 do not literally require it, though auditors look for it. For HIPAA it is proposed but not in force. Your answer depends on what data you hold and who you sell to.

Four caveats on that table. It is not exhaustive: other sector, government and national rules, and your own contracts, may also apply, and a merchant using a fully hosted checkout should ask its acquirer or assessor which PCI tests apply. The SOC 2 and ISO readings come from vendors with a commercial interest, and we sell testing too, so weigh them accordingly. We read the PCI wording through Microsoft Learn's reproduction and Strike, and DORA through an unofficial reproduction, so check the originals before relying on them. For HIPAA, the Unified Agenda entry we opened lists the rule under long-term actions with final action estimated for July 2027, which is an estimate, and Pact-One, a compliance vendor, said on a page updated 29 October 2026 that it is still not final.

In the UAE, AWS says the Information Assurance Regulation is required of entities TDRA designates as critical, and the Dubai Electronic Security Center says Dubai's Information Security Regulation applies to Dubai Government Entities. We could not confirm from public text what either requires on testing, so ask your regulator or assessor.

Our view, and it is a view and not a rule: a business holding customer data or running many tenants should treat a scoped test as mandatory in practice, at least once a year and after any major change. Verizon's 2026 Data Breach Investigations Report, covering 1 November 2024 to 31 October 2025, says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords. IBM's Cost of a Data Breach Report 2026 puts the global average cost at USD 4.99M, up 12% and a record.

The multi-tenant case is stronger still. On a shared platform, one gap in isolation is not one customer's problem, and your customers cannot see your internals to check. When one asks whether another tenant can reach their data, "we think not" is a weak answer. A dated report is a better one.

What should you do this month about AI agents and penetration testing?

What to do this month about AI agents and penetration testing depends on which side of this you are on, and many teams are on both. Items 1 to 4 are for anyone running AI agents. Items 5 to 9 are for anyone running a platform or app that holds customer data.

1. Test only systems you own or have signed permission for. Get the permission before the run, naming targets, dates and what is off limits. Check it covers the actual target and not just the company you think you are testing.
2. Write down what staff may point agents at, including outside work. One paragraph is enough. Say that third-party systems need written permission first.
3. Move every agent's scope out of the prompt. Network rules for permitted targets, short-lived credentials, human approval for high-impact actions, a stop switch and a full log.
4. Read the host's rules too. AWS and Microsoft publish theirs, and your client's signature does not speak for them.
5. Ask the table's five questions of your own platform, with written sign-off and within your host's testing rules. Use a test tenant you own, in staging where you can. In production, agree windows and rate limits first, and stop at proof of access without reading other customers' data. Write down each answer.
6. Check the defaults you never set. Service account credential mounts, RBAC on Secrets including list and watch, NetworkPolicy and whether your plugin enforces it, and access to the metadata API.
7. Ask whether you could write Manders's list. He published a step-by-step account. If someone tried those steps on your platform tonight, would your logs let you do that, and who would get the alert?
8. Say in your own terms what testing needs your written consent. Primcloud's policy is one example of the wording.
9. Find your row in the rules table, then decide. Ask your auditor and your largest customers what they expect. If nothing binds you, decide anyway, and put a date on it.

What does a scoped VAPT from us include?

A scoped VAPT from IrenicTech starts with paper: targets, roles, test windows and exclusions agreed in writing, with your signed authorization. Nothing is touched before that exists. It is the same line this post has been about, and it is where our VAPT service begins.

Our own team does the testing, and we do not subcontract it. There are four engagements, which you can buy alone or combine:

• Web & API VAPT: authentication, session handling, access control between roles and tenants, and business logic in REST and GraphQL APIs.
• Mobile App VAPT: iOS and Android builds, tested together with the API behind them.
• Network & Infrastructure VAPT: external first, internal when the scope calls for it. Exposed hosts, ports and services, weak protocols, default credentials and paths from one host to the next.
• Cloud Configuration Review: identity and access policies, public storage, network exposure and logging, checked against the CIS Benchmarks, using read-only access from you.

These work at different layers of the same problem: Web & API checks access control between tenants at the application layer, Network & Infrastructure checks paths between hosts, and the Cloud Configuration Review reads identity, network exposure and logging settings. None is sold as a test from inside a customer workload, so if that is your main question, raise it on the scoping call and we will say whether and how it fits. A scanner gives you candidates. A person then verifies them and tests what a scan cannot, such as access control between tenants and attacks that chain several flaws. We test against public methods, including the OWASP Web Security Testing Guide, PTES, NIST SP 800-115 and the CIS Benchmarks, so your auditor can check the work against something other than our word.

Each ends with the same report: an executive summary, CVSS-scored findings, proof of concept for each exploitable finding, and remediation guidance. Critical findings reach you the same day, and the report is walked through on a call with your engineers. Once you have fixed the findings, we retest them at no charge and reissue the report. You then get a signed letter stating the scope, the test dates and the outcome, for the customer, auditor or regulator who asked.

It is not the right fit for everyone. If a regulator or customer requires a test from an accredited firm, such as CREST or a regulator's approved list, tell us and we will say plainly whether our report fits. We do not do red team exercises, social engineering or physical testing. If the reader of the report needs independence on software we built or audited for you, we scope the test and hand it to an outside firm.

If an audit prompted the question, see our compliance engineering practice. Our cloud infrastructure page covers the platform side.

Tell us what you run and who is asking for proof, and ask for a scoping call. The call is free either way.

Part of our guide to AI security.

Sources: Primcloud founder Josh Manders on X: first post, screenshot, list of steps and reply to the statement; Railway co-founder Jake Cooper on X: first reply and written statement; The Stack (headline); RuntimeWire and Security Boulevard (Cooper's later replies, the promised ban); explainx.ai (what is unverified); Primcloud's Acceptable Use Policy; Railway's disclosure and preliminary report (October incident); NIST's glossary, PTES, AWS and Microsoft (testing authority); 18 U.S.C. 1030, the Justice Manual, the Computer Misuse Act and LexisNexis Middle East (general law); PCI SSC, Microsoft Learn and Strike (PCI DSS); 16 CFR 314.1, 314.4 and 314.6 (FTC); 23 NYCRR 500.1, 500.5 and 500.19 (NYDFS); DORA Article 24, Article 25 and Article 26 (unofficial reproduction); the HIPAA proposal, the Unified Agenda entry and Pact-One; Drata, TCSA and Strike (SOC 2, ISO 27001); AWS on the UAE regulation and DESC; Kubernetes on service accounts, RBAC, network policies and securing a cluster; AWS on instance metadata, its settings and newer instance types; OWASP LLM06:2025; Verizon's 2026 DBIR; and IBM's Cost of a Data Breach Report 2026. We do not link the engineer's reply or the developers' posts, because their addresses carry the names of private individuals. Verified against these sources on 5 November 2026.