How MYLO Sanitizes Telecom Documents Before AI Processing

A telecom document is rarely all secret or all harmless. The same page may contain useful instructions about registration, codecs, number format and routing together with a SIP username, password or private customer identifier. MYLO sanitizes the material before AI processing so the model can understand the technical meaning without receiving protected values it does not need.

The goal is not to turn the document into vague sample text. Good sanitization preserves relationships and field types. It should remain clear that a trunk has an authentication username and secret, while the actual values remain within the authorised local boundary.

Begin with a selected provider document

The user should choose the document for a defined task, such as preparing a new trunk proposal or understanding a provider’s number format. MYLO should not scan every appliance file or attach an entire document archive simply because one file may be relevant.

Selection is the first privacy control. A narrow provider sheet normally contains less unrelated data than an email thread or support export. If the source includes customer names, billing detail or historical conversations that do not help the configuration task, the user should remove them before submission where practical.

Access also matters. Only an authenticated user with the required page and action permission should be able to start the document-processing workflow. Uploading a document does not grant permission to change telephony.

Identify protected values and sensitive context

Sanitization looks for values that should not enter ordinary model context: SIP authentication secrets, endpoint passwords, AI-provider keys, administrator passwords, private keys and other credentials. It also needs to recognise that ordinary-looking text can be sensitive, including customer telephone numbers, email addresses, account references and internal network details.

Not every category receives identical handling. Credentials should be excluded from the model path. Other identifiers may be removed, generalised or retained only when the approved task genuinely requires them. A useful system should classify the material rather than applying one blind replacement rule to everything.

Automated detection can miss a secret hidden in prose or mistake an example for a real value. That is why document review and user responsibility remain part of the process. Sanitization reduces risk; it does not make any arbitrary upload safe.

Replace values with typed placeholders

A typed placeholder describes what was removed. Instead of sending the actual SIP password, the sanitized document can contain a marker meaning “protected SIP authentication secret.” A username can be represented as an authentication-username field, and a provider address can be classified according to whether it is protected or necessary for the task.

Typing preserves semantic usefulness. The model can understand that a configuration requires paired authentication fields, that one field is missing, or that a particular instruction applies to the registrar. A generic block of random replacement text would destroy those relationships and encourage incorrect proposals.

Placeholders must not drift. The same protected value should be represented coherently within the selected document, without being substituted by unrelated invented examples. The sanitized version should preserve headings, field labels and meaningful structure so a reviewer can follow the model’s reasoning.

Preserve meaning without preserving secrets

Consider a provider sheet that says an account must register to a named host using a supplied username and secret, then present one of several authorised caller IDs. The AI needs the relationship between registration, identity and caller ID. It usually does not need the secret value.

After sanitization, the model can help distinguish the authentication identity from the business number, ask which caller ID the customer intends to use and draft a structured trunk proposal. It should not be able to reveal the original password or copy it into a generated article, example or chat reply.

This separation supports MYLO’s broader authority model. The AI handles semantic ambiguity; deterministic local services handle protected data, validation, permissions and execution. A helpful explanation does not become permission to mutate Asterisk.

Local resolution happens after approval

If the user approves a consequential proposal, deterministic code can resolve the typed placeholders from protected local storage at the execution boundary. The model does not need to request the secret again, and the user should not paste it into the approval message.

Resolution should be limited to the approved operation and validated scope. MYLO takes the relevant pre-change snapshot, writes the supported Asterisk configuration atomically, validates it, reloads the service and checks the live result. The protected value is used where the telephony system needs it, not spread through chat or general logs.

If a required value is absent or the authorised local retrieval fails, execution stops. The safe response is to explain which protected input is missing and direct an administrator to the proper setup or retrieval path. The model must not invent a credential.

Sanitization applies beyond the prompt

Protecting the outbound prompt is only one part of the job. The original upload, sanitized derivative, model response, run events, audit record and error logs need appropriate handling. A credential removed before AI processing should not reappear in a stack trace or a downloadable diagnostic bundle.

Retention should match business policy. The organisation should decide whether the original document must be kept, who can access it, when sanitized derivatives expire and how incident evidence is preserved. Provider-side prompt retention is controlled by the customer’s selected AI-provider arrangement, not by a universal MYLO promise.

Learned or reusable material requires its own reviewed, sanitized persistence path. Approval that a technical example worked is not automatically approval to retain the source document or customer-specific content as reusable knowledge.

A worked business example

A retailer receives a PDF from its SIP provider. The file lists the registrar, supported transport, number format, two DIDs, an authentication username, an authentication password and the name of the provider’s account manager. The retailer wants an inbound support route and an outbound sales identity.

The authorised Configuration Agent selects the file for the trunk task. MYLO identifies the username and password as protected authentication fields, removes the unnecessary account-manager detail and preserves the provider instructions and number relationships in a sanitized representation. The user reviews the scope before AI processing.

The customer-selected model receives the question and sanitized context. It asks which DID should be used for sales, notes the inbound support requirement and prepares a proposal. An Administrator reviews the difference. After approval, local code resolves the protected fields, applies the bounded configuration and verifies inbound and outbound calls.

The useful meaning crossed the boundary; the SIP secret did not. The operation remains traceable without putting the secret into the conversational history.

Limits that should be stated clearly

• Sanitization is not guaranteed anonymisation of every free-text detail.
• A user can still type sensitive data directly into a question, so training and access control matter.
• Typed placeholders preserve categories and relationships; they do not give the model access to original values.
• Model output must still pass deterministic validation and human approval before consequential change.
• The customer remains responsible for the selected AI provider, its terms and provider-side retention.
• Local resolution can fail safely when a credential is absent, expired or outside the approved scope.

Document-processing checklist

• Define the task and choose only the document needed for it.
• Remove obviously unrelated customer, commercial or personal material.
• Confirm the user is authorised to submit the document.
• Review detected credentials and other protected categories.
• Check that typed placeholders preserve the document’s real structure.
• Confirm what selected sanitized context will reach the configured provider.
• Keep original values out of chat, prompts, ordinary logs and model output.
• Resolve protected values only through deterministic local execution after approval.
• Verify the final telecom outcome from live state and a controlled call.

Effective sanitization gives the AI enough meaning to assist and no unnecessary secret to retain. That is the boundary MYLO is designed to maintain.

Quality-check the sanitized representation

A useful review compares structure rather than secrets. Confirm that headings, field labels, relationships and units survived; that protected values became the correct placeholder types; and that irrelevant personal or commercial material was removed. The reviewer should be able to tell what the model is being asked to understand without reconstructing the original credential.

Watch for false confidence. A scanner may cover known text patterns while missing a password inside an image, an unusual key format or free-form instructions. A statement such as “all private data removed” should be made only when the actual supported inspection justifies it. Otherwise describe the bounded controls and residual need for human review.

Model output needs a separate check. The response must not invent a secret to replace a placeholder, turn an example value into production configuration or claim that a document proves live provider state. Structured proposals return to deterministic validation and human approval.

Test the workflow with representative documents before relying on it operationally: ordinary provider sheets, unexpected layouts, scanned pages, repeated values and deliberately embedded secrets. A failure should stop safely, identify what needs manual review and leave the original telephony configuration unchanged.

Preserve Meaning With Semantic Tokens

Sanitization replaces protected values with typed meaning: a real customer IP becomes [CUSTOMER_TELEPHONY_IP], a gateway becomes [PROVIDER_GATEWAY_IP], and an SBC becomes [PROVIDER_SBC_IP]. Passwords are removed rather than disguised. The model can distinguish customer, gateway and media roles without receiving the customer’s actual addresses or credentials.